harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-5105) [drlvm][GC]leak during gc_gen shutdown sequence
Date Mon, 12 Nov 2007 14:15:50 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-5105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541781
] 

Rana Dasgupta commented on HARMONY-5105:
----------------------------------------

Xiao Feng,
   Thanks for explaining this. I saw the non default case of disjoint spaces guarded by STATIC_NOS_MAPPING,
but could not determine if this is used for testing only etc. It's clearer now.
  I think ( IMHO )that it is probably better that all spaces acquired through VirtualAlloc
are released back using MEM_RELEASE to stop leaks, specially given the way STD_FREE works
on the individual nos/mos/los spaces. Since you are OK with this, I'll submit a modified patch
accomodating this.

Thanks,
Rana

> [drlvm][GC]leak during gc_gen shutdown sequence
> -----------------------------------------------
>
>                 Key: HARMONY-5105
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5105
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Windows
>            Reporter: Rana Dasgupta
>         Attachments: FreeMem.patch, FreeMem2.patch
>
>
> On Windows vm_unmap_mem() fails to release memory back to OS. STD_FREE uncommits the
relevant nos, mos etc. spaces, these heap regions are now unmapped and VirtualFree cannot
be called on these locations. Moreover, VirtualFree with MEM_RELEASE nees to be be called
from the exact allocation base, or the call will fail. Added an assert so that Memory tools
are not the only way to catch the error.
> Don't commit until gc people review.

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