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 Sat, 28 Apr 2007 06:54: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_design001_gen_gen.diff

The second_design001*.diff files comprise a prototype of a simpler approach to reclaiming
fat lock resources associated with dead java objects.  This patch is not yet ready to commit.

The second_design* approach does not use weak references, which means the GC and TM do not
need to coordinate the maintenace of weak ref pointer lists.  The second_design* approach
requires only a single pass of the fat lock array.

Additional detailed info:  GCV5 was used.  I have looked at GCV4.1 but  so far have been unable
to figure out how to modify this code to support the 2nd design.  To support generic collection
of native resources that are associated with Java objects, there needs to be a GC/VM interface
for forcing a major GC.  It seems gc_force_gc() needs to be somehow involved.  The force gc
part of the design has not been completely figured out.  My thinking is that if it is too
hard to call gc_force_gc(major_collection) from fat monitor inflate, it might make sense to
set a flag that will cause a major collection at some future convenient GC event (like swapping
nurseries).  The concept is to set this flag while there is still 50% free space in the fat
lock table.  The idea is that a major collection will free native resources before the system
hard crashes.

The second_design* patches pass an extended version of ManyThreadsTest.java.  The original
java file was enhanced to allocate java objects while threads are creating/dying.  This forces
the GC to clean the fat lock table (and is actually more representative of typical workloads.)

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