investigate semantics of mc_morecore

[larceny-trac-import]

_Reported by: pnkfelix on Thu Jul 20 17:31:44 2006 _ (related to ticket:335)

(see also SemanticsOfMorecore)

Lars changed the name of an explicit garbage collect millicode operation to morecore, with the intention that morecore wouldn't actually invoke the collector if we had sufficient space available.

It isn't clear what "sufficient space" is supposed to mean though. From Lars' comments when he made the change (changeset:963 though changeset:972; changeset:970 and changeset:971 hold the most information about the change), sufficient space may mean just enough space for a new pair. But he then used morecore to allocate closures on the Nasm backend, which take up more than a pair's storage.

The unclear semantics of morecore led to bugs with in PetitLarceny (see Ticket #92). PnkFelix worked around those bugs by putting in some very conservative behavior; it would be better if someone went through and determined what the semantics of morecore is supposed to be, and whether we actually need it at all.

[larceny-trac-import]

Author: pnkfelix punt

[larceny-trac-import]

Author: pnkfelix I do want to do this at some point, but its not a priority for 0.94...

[larceny-trac-import]

Author: pnkfelix Problems with the dynregion branch led me to dive into this problem once again.

But this time I think I have an answer: the SPARC runtime's mc_morecore invokes yh_make_room, '''not''' gc_collect(..., 0, ...).

So I think the intention has always been that mc_morecore be an invocation of yh_make_room. But why did Lars not implement it that way? My current hypothesis is that in Petit Larceny he was using mc_morecore to allocate structures larger than 4 KB. Since yh_make_room is only guaranteed to set things up so that 4 KB are available, Lars decided to change mc_morecore so that it called the collector instead.

I need to see whether we now have an invariant that mc_morecore is only used for allocating structures <= 4 KB. If so, then I bet we can switch the runtime system to call out to yh_make_room instead of gc_collect.

[larceny-trac-import]

Author: pnkfelix In changeset:5429 I adopted the same change that Lars used for SPARC when he resolved ticket:335.

But I do not think making a direct call to a procedure in the young_heap_t interface is the appropriate design choice; I think it would have been better to extend the GC interface to expose the make_room method or something like it.

So when I incorporate the change into the trunk, we should evaluate the design space here.

[larceny-trac-import]

Author: pnkfelix See changeset:5605.

[larceny-trac-import]

Author: pnkfelix Assuming that changeset:5605 builds cleanly and does not hurt performance (it should actually give the stopcopy collector a significant performance boost), the next thing I should consider is reverting changeset:3104, and add an assertion that request_bytes > 0.