CallSite relinking

[Attila Szegedi]

Yeah, you'll need to keep a method handle for your linking method around.

Do you need to return them into an actual "unlinked" state, or do you just need to make sure they're relinked at the time of the next invocation? I found that for my use cases, the latter is actually sufficient - in my dynalink framework, I'll keep a MethodHandle to a "relinkAndInvoke" method in my relinkable call site class (see <https://github.com/szegedi/dynalink/blob/master/src/org/dynalang/dynalink/RelinkableCallSite.java>) and various subclasses of it use it to force relinking when necessary, i.e. i.e. MonomorphicCallSite in <https://github.com/szegedi/dynalink/blob/master/src/org/dynalang/dynalink/MonomorphicCallSite.java> will use it as the "false" branch of a guardWithTest().

If you need atomicity in invalidation, you can also use java.lang.invoke.SwitchPoint instead.

Attila.

On Mar 6, 2011, at 9:42 PM, Mark Roos wrote:

> I am at the point where I need to plan for the insitu replacement of methods.  For this I need to relink the call sites 
> which reference the selector of the method being replaced.   Looking over the latest api I don't see the old methods 
> which one could use to force a callsite to an unlinked state.   
> 
> Is the approach now to use setTarget to return the callsite to its original post bootstrap state? Since to do this I 
> need to know the original boostrap method and parameters, and I see no api to get them, I assume that I need 
> to keep them as part of my call site implementation. 
> 
> Am I heading the right way? 
> 
> regards 
> mark 
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110306/a07ec029/attachment.html