[jira] Commented: (HARMONY-5105) [drlvm][GC]leak during gc_gen shutdown sequence

["Xiao-Feng Li (JIRA)" <ji...@apache.org>]

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