Rémi Forax wrote:
Le 25/04/2010 18:01, Jochen Theodorou a écrit :
Rémi Forax wrote:
[...]
For more details see
http://wiki.jvmlangsummit.com/DinnerAtPiatti
(search for section invalidation)
true I fully forgot about invalidation... so how would I do it? most
probably a boolean in the call site that is not volatile and gets
flagged from outside if a meta class change happened. On each usage of
the call site this flag would be checked to see if the call site is
still valid.
Invalidation trashes the call site, you have to rebuilt it.
sure, but how is the trashing done? I know in case of invokedynamic this
is done through the JVM, but I need something for Java5 and Java6 as well.
[...]
I don't think it's possible to do invalidation without the proper
support by the VM.
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.
this sounds quite inefficient
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;
}
sure, that part is not the problem
[...]
I don't see how to emulate this.
If someone find I will be happy to implement the solution in the
backport :)
This depends on what exactly you need. For Groovy I was thinking about
something like this:
- guard in a invocation
if (invalid) {
replace this callsite
} else {
target.invoke
}
- after meta class change
for (callsite : relevantCallsites) { callsite.invalid = true }
bootstrap would still be something like the above. Since "invalid" is a
boolean I don't have to fear partially initialized objects and since I
don't need instant publication of the new value, I can let the change
ride piggy back on another memory barrier. That means the call site will
be recognized as invalid eventually at a later time.
But in this pattern I have the next problem. If the call site is not
immutable, then I have again to use synchronization or something similar
and the total win is again zero.
It is like a cat hunting its tail.
So no solution yet. That is why I was looking for something like fences.
The above can only be a solution for invokedynamic, but not for the
backport unless you buy the horrible inefficient way. Well not that
inefficient, but it is not good for performance at all.
bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
--
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.
