[Vm-dev] Re: primitive retry across suspension for OwnedLock waitAcquire (was: Interpreter versus StackInterpreter hierarchy)

[Ben Coman]

On Sat, Jun 4, 2016 at 10:10 AM, Ben Coman <btc at openinworld.com> wrote:
>
> Now an assert failed in #checkForAndFollowForwardedPrimitiveState
>    self assert: (self saneFunctionPointerForFailureOfPrimIndex: primIndex)].
>
> but we have correctly restored newMethod =
>      16rC0DA18: a(n) CompiledMethod nbytes 34
>      16r20009 =65540 (16r10004)
>      16r1790AB0 #iAmMethodExperimentFailAndWakeOther
>      16r5C6630 #primitiveFail  16r147A3B8 an AdditionalMethodState
>      16r17D1090 a ClassBinding #OwnedLock -> 16r01116370
>
> and correctly restored primIndex = 561.
> but #saneFunctionPointerForFailureOfPrimIndex:
> uses a a stale primitiveFunctionPointer which needs to be saved across
> the context switch.
>
> ---------------
> Now I am a little confused about  primitiveFunctionPointer.  By name I
> would expect a pointer and to use #storePointer:toObject:withValue ,
> but actually I find...
>    primitiveFunctionPointer
>         ==>  #primitiveSuspend    (which btw is stale)
>    self functionPointerFor: primIndex inClass: objectMemory nilObject
>        ==> #primitiveExperimentFailAndWakeOther    (which is correct)
>
> So what store method should I use for primitiveFunctionPointer ?
>
> cheers -ben

As a quick check, under the assumption that a newly opened image
doesn't have any forwarders for a primitive to fail on, and that the
"reader" image probably hasn't done any becomes,  I just commented the
call to #maybeRetryFailureDueToForwarding  out of
#slowPrimitiveResponse.  Thus running...

    OwnedLock new experiment1. !

produces...

   OrderedCollection(0 11 12 21 22 14 23 24 8 9)

which is exactly what I was hoping for.

So having *mostly* produced a technical proof of concept (for
StackVM), the meta-question is whether a change like this worth
pursuing?  Apart from my own need for the OwnedLock
primitiveWaitAcquire, I have cluelessly wondered if there might be any
benefit for multi-threading or callback patterns, now or in the
future.

Also, are there any obvious/known difficulties to be expected doing
this with JIT side?

cheers -ben

P.S. I could never imagine getting so far in a few days without the
Simulator.   It is **really**  cool to be bale to load an Image on an
unmodified VM, then switch in some new VM code while the Image is
running.