[jira] Updated: (HARMONY-2742) [drlvm] Memory leak in threading system.

["weldon washburn (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HARMONY-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

weldon washburn updated HARMONY-2742:
-------------------------------------

    Attachment: second_design002.diff

The original ManyThreadsTest.java now runs successfully but very slowly.  The reason is becase gc_force_gc() does not have a parameter to force a major collection.  A major collection is the only way I (currently) know how to make the GC give an accurate accounting of all the live fat table entries.   I suspect this test is running really slow because many minor collections are invoked without freeing any fat lock table entries.

The current design has a quota of 50% of the fat lock table.  The table is hardcoded at 8KB entries.  Its easy to make the table dynamically expandable.  Its just not a priority until a workload shows we need to do this.  In any case, a quota approach was taken because forcing a major collection during a fat lock inflation means that all callee's of fat lock inflation need to be in a suspend enabled state.  It turns out there is a code path from  gen_monitor_enter_fast_path_helper() that can not allow the suspend enabled state because there are unaccounted for raw interior heap pointers on the stack.  In specific, the pointer to an object's lockword.  The quota design gets around this problem by allowing the fat table occupancy to exceed the quota in anticipation that future fat lock allocations will cause a gc_force_gc().  The gc_force_gc() is called at (most) entry points that can cause a fat lock inflate.

This patch also uncovers something that looks like a bug.  It turns out that IDATA VMCALL jthread_monitor_enter(jobject monitor); is sometimes called with hythread_t.disable_count = 0 and sometimes with disable_count = 1;  It seems that from design rules, jthread_monitor_enter should always be called with disable count = 0.   Also, I think there are assert()'s in the code that jthread_monitor_enter() calls that assume this design rule. The "hack" to workaround this issue is to only call gc_force_gc() if disable_count == 0.

The next step is to clean up this code, merge with the latest svn HEAD and run regressions on all four (4) regression platforms  -- lin32, lin64, win32, win64.  It should then be ready for review and optimistically commit.

There are two choices for fixing the gc_force_gc() problem.  Either add a call parameter like:
gc_force_gc(MINOR), gc_force_gc(MAJOR);  or change the semantics of gc_force_gc() so that it always does a major collection.





> [drlvm] Memory leak in threading system.
> ----------------------------------------
>
>                 Key: HARMONY-2742
>                 URL: https://issues.apache.org/jira/browse/HARMONY-2742
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>            Reporter: Pavel Afremov
>         Assigned To: weldon washburn
>         Attachments: ManyThreadsTest.java, release_fat_monitors_gcv4.1.patch, second_design001_gc_gen.diff, second_design001_thread_manager.diff, second_design002.diff, second_design___ManyThreadsTest.java
>
>
> Creating, starting and joining thread is source of memory leak. This leak is not fixed by patch from HARMONY-2437.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.