[Vm-dev] VM Maker: VMMaker.oscog-eem.1881.mcz

David T. Lewis lewis at mail.msen.com
Tue Jun 7 01:34:37 UTC 2016


On Mon, Jun 06, 2016 at 07:56:19PM +0000, commits at source.squeak.org wrote:
>  
> Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
> http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1881.mcz
> 
> ==================== Summary ====================
> 
> Name: VMMaker.oscog-eem.1881
> Author: eem
> Time: 6 June 2016, 12:55:12.14917 pm
> UUID: c51b1764-ddf8-49fc-92bd-d587b3d65101
> Ancestors: VMMaker.oscog-eem.1880
> 
> On Spur, handle external primitive failures answering PrimErrNoMemory by doing a scavenge and retrying and then on subsequent PrimErrNoMemory failure a full GC and then retrying.  Rename maybeRetryFailureDueToForwarding to maybeRetryPrimitiveOnFailure.
> 
> In the Cogit, change the retry mechanism so that the primitive call is made in the run-time, instead of the run-time answering whether the primitive should be retried and returning to machine code that then retries.
> 
> In the simulator, go through the contortions to map[ back whatever primitiveFunctionPointer is to that which dispatchFunctionPointer: accepts.
> 
> Discussion:
> First, this mechanism applies only to external (plugin) primitives.  Spur's core primtives are written in the expectation that image-level primitive failure code will deal with the failure and retry.  This corresponds to the VisualWorks style and allows the image to implement GC policy (e.g. to favour reclamation over growth).  So with the current Spur code, heavily influenced by the author's experience with VisualWorks, it would be inapproprate to retry corte primitives on being out-of-memory.  The pathology is that attempts at very large allocations which will inevitably fail will cause a GC in the VM, very possibly followed by a GC from the image level primitive failure code.  Whereas leaving it to the image, the image code may be intellkigent enough to spot an allocation too large to ever succeed and avoid the GC altogether.
> 
> I'm not sure if I like this auto-retry or not.  Perhaps it is a good idea and the image-level primitive failure code should be changed; there would certainly be fewer image-level methods.  But that means fewer hooks for the image to implement GC policy.  retryPrimitiveOnFailure which manages the retry isn't exactly simple (mapping back the primitiveFunctionPointer to something dispatchFunctionPointer: can manage isn't simple either, but that's simulation only, and so its complications carry much less weight).
>

I do not have enough experience with the different strategies to provide
a useful critique, but with respect to retrying for plugin primitives, I
think that it does make sense to do that. Most allocations in plugin
primitives are small in size, usually for allocating relatively small strings
and arrays. The probability of needing a retry in one of these primitives
is low, and the probability of the retry being successful is high. Having
this be automatic seems like a good thing to do.

In addition, some plugin primitives involve interaction with external
libraries and resources, such that a primitive may not be easily restartable
if it fails part way through its processing. For these primitives, we would
want to attempt to handle any needed memory allocations within the primitive,
without going back to the image to ask for help.

It does feel a bit inconsistent to have the policies for plugin primitives 
and VM primitives be different, but given that the goal is to enable
GC policy control from the image, it makes sense. Most primitive calls that
result in a need for CG will be VM primitives (not plugin primitives) and
if they can uniformly assume that the image is going to take responsibility
for reacting to low space conditions, then it should be possible to put the
control for this into the image and leave it out of the VM primitives.

Dave
 


More information about the Vm-dev mailing list