Re: Automatic garbage collection is enabled!
"David Griswold" <[email protected]> Sun, 2 Nov 2008 04:50:22 -0800
| Newsgroups | gmane.comp.lang.smalltalk.strongtalk |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_32854_14869601.1225630222984 Content-Type: text/plain; charset=ISO-8859-1 Hm, that is not ideal. It would be highly desirable for there to not be holes in the GC policy coverage. Ideally, we want a policy that covers all cases, regardless of what causes the allocation, otherwise we will get really strange behavior, such as code that doesn't do any explicit allocation but allocates contexts or blocks implicitly, causing totally different VM GC behavior than when code that does explicit allocation is running. On Sat, Nov 1, 2008 at 3:39 PM, talksmall <[email protected]>wrote: > > Dave, > Anything that the VM allocates internally uses the old logic and I > haven't touched the behaviour for block and context allocation. > > I've added some parameters to the allocate methods on the various > klass subclasses to indicate whether a scavenge is allowed when newgen > is full (and therefore, implicitly, expansion of oldgen if it, too, is > full). If not the methods just return NULL, which the primitive catch > and return a marked symbol to invoke the failure blocks. > > The two extra flags have default values that equate to the previous > behaviour, so the only place that I made changes was in the new > primitives and the amendment to the optimised allocation primitives > used by the compiler. Since the name of the replacement allocation > primitive for non-indexables matches the same pattern as the old name, > it gets replaced by the PrimInliner in just the same way. I had to > patch the primitiveNew[0-9] code so that they return a marked symbol > rather than calling scavenge, but that seems to work just fine. > > Regards, Steve > > On Nov 1, 8:21 pm, "David Griswold" <[email protected]> > wrote: > > That's great! Something that has been needed for a long time. > > Question: how does this work for things like block closures that are not > > allocated explicitly, and thus have no fail block in the image code? > > -Dave > > > > On Sat, Nov 1, 2008 at 12:44 PM, talksmall <[email protected] > >wrote: > > > > > > > > > I've just checked in a change (r154) to add automatic garbage > > > collection to the VM. Actually the code to automate garbage collection > > > is Smalltalk code invoked in the fail blocks of the various allocation > > > primitives. The change to the VM just allows the primitive to fail > > > when insufficient space is available to fulfil the allocation. > > > > > To use this code you will need to download and replace your image and > > > source directory with the version found in the strongtalk-autogc- > > > r154.tgz file on the Downloads tab of the project website. > > > > > I've updated the relevant issue with some brief details of the > > > changes. > > > > > Regards, talksmall > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Strongtalk-general" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en -~----------~----~----~----~------~----~------~--~--- ------=_Part_32854_14869601.1225630222984 Content-Type: text/html; charset=ISO-8859-1 Hm, that is not ideal. It would be highly desirable for there to not be holes in the GC policy coverage. Ideally, we want a policy that covers all cases, regardless of what causes the allocation, otherwise we will get really strange behavior, such as code that doesn't do any explicit allocation but allocates contexts or blocks implicitly, causing totally different VM GC behavior than when code that does explicit allocation is running.<div> <br><div class="gmail_quote">On Sat, Nov 1, 2008 at 3:39 PM, talksmall <span dir="ltr"><<a href="mailto:[email protected]">[email protected]</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <br> Dave,<br> Anything that the VM allocates internally uses the old logic and I<br> haven't touched the behaviour for block and context allocation.<br> <br> I've added some parameters to the allocate methods on the various<br> klass subclasses to indicate whether a scavenge is allowed when newgen<br> is full (and therefore, implicitly, expansion of oldgen if it, too, is<br> full). If not the methods just return NULL, which the primitive catch<br> and return a marked symbol to invoke the failure blocks.<br> <br> The two extra flags have default values that equate to the previous<br> behaviour, so the only place that I made changes was in the new<br> primitives and the amendment to the optimised allocation primitives<br> used by the compiler. Since the name of the replacement allocation<br> primitive for non-indexables matches the same pattern as the old name,<br> it gets replaced by the PrimInliner in just the same way. I had to<br> patch the primitiveNew[0-9] code so that they return a marked symbol<br> rather than calling scavenge, but that seems to work just fine.<br> <br> Regards, Steve<br> <br> On Nov 1, 8:21 pm, "David Griswold" <<a href="mailto:[email protected]">[email protected]</a>><br> wrote:<br> <div class="Ih2E3d">> That's great! Something that has been needed for a long time.<br> > Question: how does this work for things like block closures that are not<br> > allocated explicitly, and thus have no fail block in the image code?<br> > -Dave<br> ><br> </div>> On Sat, Nov 1, 2008 at 12:44 PM, talksmall <<a href="mailto:[email protected]">[email protected]</a>>wrote:<br> <div><div></div><div class="Wj3C7c">><br> ><br> ><br> > > I've just checked in a change (r154) to add automatic garbage<br> > > collection to the VM. Actually the code to automate garbage collection<br> > > is Smalltalk code invoked in the fail blocks of the various allocation<br> > > primitives. The change to the VM just allows the primitive to fail<br> > > when insufficient space is available to fulfil the allocation.<br> ><br> > > To use this code you will need to download and replace your image and<br> > > source directory with the version found in the strongtalk-autogc-<br> > > r154.tgz file on the Downloads tab of the project website.<br> ><br> > > I've updated the relevant issue with some brief details of the<br> > > changes.<br> ><br> > > Regards, talksmall<br> <br> </div></div></blockquote></div><br></div><br> --~--~---------~--~----~------------~-------~--~----~<br> You received this message because you are subscribed to the Google Groups "Strongtalk-general" group. <br> To post to this group, send email to [email protected] <br> To unsubscribe from this group, send email to [email protected] <br> For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en<br> -~----------~----~----~----~------~----~------~--~---<br> <br> ------=_Part_32854_14869601.1225630222984--