Thanks Attila, I am doing the same as you ( just want to revert the
target)
regards
mark
From:
Attila Szegedi
To:
Da Vinci Machine Project
Date:
03/06/2011 10:34 PM
Subject:
Re: CallSite relinking
Sent by:
[email protected]
Yeah, you'll need to keep a method handle for
If a SwitchPoint is invalidated, will all method handles created with its
guardWithTest release the reference to "target" (since they no longer need it)
and only keep the reference to "fallback", so in theory, "target" can be GCed?
Attila.
___
mlvm-dev
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 dyn
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
Hi Howard,
thank you for your comments.
On 03/07/2011 12:25 AM, Howard Lovatt wrote:
> The new API looks great. I think all the simplifications made,
> particularly around CallSite and no longer having a Bootstrap, have
> really helped. The methods isWrapperInstance, wrappedInstanceTarget,
> and w
The new API looks great. I think all the simplifications made,
particularly around CallSite and no longer having a Bootstrap, have
really helped. The methods isWrapperInstance, wrappedInstanceTarget,
and wrapperInstanceType are nice additions to the API.
The requirement that a SAM (in MethodHandle
I have been working with method lookup and caching using gwt which seems
to work well.
However to get it to work I had to set up the casting in a way which was
not obvious to me.
In my Smalltalk implementation all ST objects are instances of a single
java class ( RtObject )
so I was thinking th
