On 4/25/2010 1:18 PM, Rémi Forax wrote:
I don't think it's possible to do invalidation without the proper
support by the VM.
As I understand it, even with callsite caching the callsite has to check
that the class of the receiver & arguments are the same as last time,
before it can use the method from last time. So at each callsite, we
need an object that records these things. When the receiver's metaclass
changes, couldn't it go through all such objects and set the receiver to
null or a sentinel value? They might have to be AtomicReferences in
that case.
Alternately, the object could contain a boolean "valid" field, and when
the metaclass is changed, its sets it to false in all relevant objects.
I'm assume that it's ok for the change to take effect at different times
in different threads.
Best,
Martin
When an invalidation is requested, all threads run until each one of
them reach a safepoint,
when all threads wait, callsites in the bytecode can be reset.
Because Linkage.invalidation() is always called under a lock,
there is no publication problem if the bootstrap method lookups
for metaclass info under the same lock.
Example:
- a metaclass change:
synchronized(metaclass_lock) {
Linkage.invalidateAll();
metaclass.change_method(...);
}
- a bootstrap method:
CallSite boostrap(Class<?> declaringClass, String name, MethodType type) {
CallSite callsite = ...
MethodHandle target;
synchronized(metaclass_lock) {
target = metaclass.lookup_member(...);
}
callsite.setTarget(target);
return callsite;
}
because you only do synchronization in bootstrap method and
this method is not called often (once and once by invalidation)
you should not have performance problem.
I don't see how to emulate this.
If someone find I will be happy to implement the solution in the
backport :)
I should try it out at least.
bye blackdrag
Rémi
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
