[Gc] Optimal memory management

Tim Harrington tim@mobiledesigns.com
Mon, 25 Aug 2003 16:32:30 -0700


This is a multi-part message in MIME format.

------=_NextPart_000_0053_01C36B26.7A55ABB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I have a somewhat unique situation with the collector and could use some =
guidance.  In my situation, the gc code allocates memory from a =
particular heap unless it's a fairly large allocation (>64K).  In that =
case, the memory is returned from a heap much "further away" in memory.  =
For instance, small allocations come from the 0x004nnnn range but large =
allocation come from the 0x6nnnnnnn range.

It appears that the collector keeps a high and low water mark of =
addresses it allocates.  Is it true that it scans ALL memory addresses =
between those marks?  I'd hate for it to run all the addresses that are =
not necessarily valid.  I've looked at GC_add_roots() to manage the =
memory externally, but there's no easy way to remove the root once it's =
added so there's not much I can do when the memory is deallocated.

Maybe I'm just confused and the collector actually knows about the holes =
between allocations.  It's been a while since I ported it so my =
knowledge of the innards is somewhat fuzzy.

------=_NextPart_000_0053_01C36B26.7A55ABB0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I have a somewhat unique situation with =
the=20
collector and could use some guidance.&nbsp; In my situation, the gc =
code=20
allocates memory from a particular heap unless it's a fairly large =
allocation=20
(&gt;64K).&nbsp; In that case, the&nbsp;memory is returned from =
a&nbsp;heap much=20
"further away" in memory.&nbsp; For instance, small =
allocations&nbsp;come from=20
the&nbsp;0x004nnnn range but large allocation come from the 0x6nnnnnnn=20
range.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>It appears that the collector keeps a =
high and low=20
water mark of addresses it allocates.&nbsp; Is it true that it scans ALL =
memory=20
addresses between those marks?&nbsp; I'd hate for it to run all the =
addresses=20
that are not necessarily valid.&nbsp; I've looked at GC_add_roots() to =
manage=20
the memory externally, but there's no easy way to remove the root once =
it's=20
added so there's not much I can do when the memory is =
deallocated.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Maybe I'm just confused and the =
collector actually=20
knows about the holes between allocations.&nbsp; It's been a while since =
I=20
ported it so my knowledge of the innards is somewhat fuzzy.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0053_01C36B26.7A55ABB0--