harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-5105) [drlvm][GC]leak during gc_gen shutdown sequence
Date Sun, 11 Nov 2007 00:01:50 GMT

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

Xiao-Feng Li commented on HARMONY-5105:

Rana, thanks for the patch. It has an issue to resolve. GCv5 can have discontinued spaces,
i.e., There can be a gap unmapped between NOS and MOS. To unmap from the heap start for both
NOS and MOS may have problem for this case. 

Actually GCv5 may work in this way: to unmap a page in NOS and at the same time map a page
in MOS. This is important for NOS and MOS to share the whole heap with variable space sizes,
while keeping the total heap size unchanged.  The functions are in blocked_space_extend()
and blocked_space_shrink() in common/gc_space.h. We use vm_.de/commit_mem() for the operations,
which in turn call VirtualAlloc/VirtualFree in Windows with MEM_DE/COMMIT options. That's
why we need to release the spaces of NOS and MOS seperately. This working scenario is not
in the default mode, guarded with macro STATIC_NOS_MAPPING, where NOS is mapped at a specified
virtual address (NOS boundary). In default mode, NOS and MOS are continuous and their boundary
is only a variable pointing to some place in the heap. 

So we should MEM_RELEASE NOS and MOS separately for the STATIC_NOS_MAPPING case, and together
for the !STATIC_NOS_MAPPING case.  (Or can we simply always MEM_DECOMMIT NOS and MOS separately?
MEM_DECOMMIT without MEM_RELEASE may not cause real problem if the VM is going to shutdown
anyway. I am not sure.)

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

View raw message