[Gc] Leaking Boehm GC on CE 6

DrPizza DrPizza at quiscalusmexicanus.org
Mon Jan 12 09:00:34 PST 2009


I'm pretty sure that it is shared.  MS says that it is shared.  On WinCE 5 (WinMob 5, 6) there is a total of 4 GiB address space. The top 2 GiB is off-limits and belongs to the kernel. The bottom 32 MiB is slot 0.  The next 1 GiB is the 32 application slots (so that finishes at 1 GiB + 32 MiB).  The remainder (from 1 GiB + 32 MiB up to 2 GiB) is shared.  Each application gets its own 32 MiB private chunk, and can do further allocations from the shared space (e.g. VirtualAlloc requesting >2 MiB).  The entire address range is shared (read and write), which makes IPC much easier, but also results in inadequate memory protection. 

In WinCE 6 (which won't be used 'til WinMob 7, sadly), the top 2 GiB is off-limits kernel memory, and the bottom 2 GiB is totally private to each application.

References:
http://msdn.microsoft.com/en-us/library/aa450572.aspx
http://msdn.microsoft.com/en-us/library/aa914933.aspx
http://msdn.microsoft.com/en-us/library/aa450975.aspx

etc.

Now, whether or not the change from bottom 2 GiB shared to bottom 2 GiB private has repercussions for the GC, I don't know.  But it wouldn't surprise me.

> -----Original Message-----
> From: Craig Vanderborgh [mailto:craigvanderborgh at gmail.com]
> Sent: 12 January 2009 16:16
> To: DrPizza
> Subject: Re: [Gc] Leaking Boehm GC on CE 6
> 
> I don't believe the "rest shared" is the case on CE/WM 5.  There is
> indeed a 32MB limit for the "low" part of the address space.  But the
> upper address space - the LMA - is not shared.  We tweaked Boehm GC so
> that it would allocate all of its blocks from the so-called "Large
> Memory Area" (LMA), which is above the 32MB slot in the CE address
> space.  You can do this with a special incantation of VirtualAlloc
> that is straightforward to use.  So as far as I know - and what I've
> read in the CE documentation - there should be no noticeable
> difference since we were already allocating everything in the LMA.
> And the LMA is not shared between processes.  About the only
> difference might be that the addresses of the blocks coming from
> VirtualAlloc might now be pretty different from what they've been in
> the past.
> 
> I don't mean to be at all dismissive because something in this domain
> could easily be causing this problem.
> 
> 
> On Mon, Jan 12, 2009 at 10:53 AM, DrPizza
> <DrPizza at quiscalusmexicanus.org> wrote:
> > I thought WinCE 6 totally changed the memory map, going from the
> awful 32 by 32 MB slot with the rest shared architecture of previous
> WinCE to a proper 2/2 GB split protected memory system.
> >
> >
> >> -----Original Message-----
> >> From: gc-bounces at napali.hpl.hp.com [mailto:gc-
> >> bounces at napali.hpl.hp.com] On Behalf Of Craig Vanderborgh
> >> Sent: 12 January 2009 05:12
> >> To: gc at napali.hpl.hp.com
> >> Subject: [Gc] Leaking Boehm GC on CE 6
> >>
> >> Hello!
> >>
> >> Many years ago (back in 2003 to be exact) Hans Boehm and others
> helped
> >> us get Boehm-GC working correctly on gcj 3.3 on arm-wince-pe
> (Windows
> >> CE 3.0, at that time).  Everything - particularly that modified-for-
> CE
> >> build of Boehm GC - has been working extremely well until recently.
> >> We are extremely grateful for both the help we received then and the
> >> reliable and performant operation that Boehm GC has delivered over
> the
> >> years.
> >>
> >> Then along came Windows CE 6.  gcj/boehm still work without
> crashing,
> >> but on CE 6 we are experiencing severe leaking.  Specifically: a gcj
> >> binary that works perfectly (without leaking) on Windows CE 4/5
> >> exhibits fairly large memory leaks when run on CE 6.
> >>
> >> This is baffling to say the very least.  As far as I can tell, the
> >> memory map on Windows CE 6 is the same and I'm not aware of any
> reason
> >> WHY the Boehm GC would leak on CE 6 when it does not on other
> earlier
> >> versions.
> >>
> >> I am gearing up for what I expect will be a long and difficult
> project
> >> to find and fix this problem.  I need some ideas about where I could
> >> look for the problem, and some idea of whether there might be fixes
> >> for the GC in versions after 6.2 that might be relevant.  I have
> >> ported the "test.c" that's used to build gctest to arm-wince-pe
> >> (GNUWINCE), and here is the output from gctest.exe on Windows Mobile
> 5
> >> (no leaking):
> >>
> >> Completed 1 tests
> >> Allocated 560621 collectable objects
> >> Allocated 101 uncollectable objects
> >> Allocated 1250000 atomic objects
> >> Allocated 11480 stubborn objects
> >> Finalized 2206/2206 objects - finalization is probably ok
> >> Total number of bytes allocated is 59998108
> >> Final heap size is 3739648 bytes
> >> Collector appears to work
> >>
> >> Whereas the same gctest.exe binary run on CE 6 produces the
> following:
> >>
> >> Completed 1 tests
> >> Allocated 560621 collectable objects
> >> Allocated 101 uncollectable objects
> >> Allocated 1250000 atomic objects
> >> Allocated 11480 stubborn objects
> >> Finalized 1931/2206 objects - finalization is probably ok
> >> Total number of bytes allocated is 59998108
> >> Final heap size is 11591680 bytes
> >> Unexpected heap growth - collector may be broken
> >> Collector appears to work
> >>
> >> Thus even the fairly simple standard "gctest.exe" exhibits the
> >> problem: not all allocated objects have been finalized - presumably
> >> because they were not identified during the mark phase.
> >>
> >> It's early days on this effort, but right now I am adrift.  Any
> >> guidance or suggestions on how to proceed would be greatly
> >> appreciated.
> >>
> >> Thanks in advance!
> >> Craig Vanderborgh
> >> Voxware Incorporated
> >> _______________________________________________
> >> Gc mailing list
> >> Gc at linux.hpl.hp.com
> >> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> >



More information about the Gc mailing list