harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "weldon washburn (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-2742) [drlvm] Memory leak in threading system.
Date Fri, 04 May 2007 16:40:15 GMT

     [ 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.

View raw message