harmony-commits mailing list archives

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

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

Peter Novodvorsky updated HARMONY-2742:
---------------------------------------

    Attachment: updated_2742_007.patch

updated patch, fixed some faults Pavel noticed:

1.       Remove IS_FAT_LOCK macros from GC.[Washburn, Weldon] Xiao Feng plans to fix this
after the commit.

[Rebriy, Pavel] We can move it to VM side and we don't need any GC team support.

2.       Rename vm_notify_native_obj_attached function to something more common.[Washburn,
Weldon] any suggestions?

[Rebriy, Pavel] vm_notify_life_obj() is an example

3.       For file ManyThreadsTest.java remove ^M at the end of lines.[Washburn, Weldon] good
idea

4.       Line 370-375 - may be better use calloc function here?[Washburn, Weldon] good idea

5.       Line 381 - any race condition is here? Do we need this assert?[Washburn, Weldon]
there might be a race condition.  The note is to remind us to think through the synchronization
issues carefully.  The, "assert(live_table[array_cursor] == 0);" is useful.  A free fat lock
should never be marked by the GC as live.

[Rebriy, Pavel] If race condition is over here, some locks should protect the code. It very
hard to fix race condition on Eclipse application later...

6.       Line 398 - better to use DIE macros here.[Washburn, Weldon] good idea

7.       Line 437 - remove commented printf.[Washburn, Weldon]  I want to leave it in for
a while.  It is a useful debug tool

[Rebriy, Pavel] Better use TRACE here.

8.       Line 441 - Remove hythread_fat_lock_quota function? It's do nothing.[Washburn, Weldon]
It works in conjunction with gc_force_gc.  It will be used once gc_force_gc is implemented.

[Rebriy, Pavel] J I could change it to:

 

+UDATA hythread_fat_lock_quota() {

+

+    if ( number_of_occupied_array_slots > MAX_FAT_TABLE_ENTRIES/2

+         && !tm_self_tls-> disable_count)  {

+         return ~((UDATA)0);

+    } else {

+         return 0;

+    }

+}

 

9.       Line 467 - What's the hack? Use DIE macros here.[Washburn, Weldon] Good idea

10.   Line 491 - move initialization of lock_table to init_group_list function.[Washburn,
Weldon]  good idea.  It should be done after the initial commit.



 


> [drlvm][thread] 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_design003.patch, second_design004.patch,
second_design005.patch, second_design006.patch, second_design___ManyThreadsTest.java, updated_2742_007.patch
>
>
> 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.


Mime
View raw message