Le 26/04/2010 00:05, Jochen Theodorou a écrit :
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.
for java5 and java6, rely on polling at each calls and
advertise the users that if they use jdk7 they will see a performance
boost :)
[...]
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
It's inefficient but less than polling at each invokedynamic.
This is how devirtualisation or GC threads cooperation currently works
at least in Hotspot and JRockit.
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.
The problem of publication is that you can see partially initialized value.
By example:
metaclass.changeMethod();
valid = true;
can be re-organized:
valid = true;
metaclass.changeMethod();
or worst, if changeMethod contains two instructions:
instruction1;
valid = true;
instruction2;
Also maintaining a list of all callsites to invalidate can perhaps
not worth it.
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.
call site is not immutable. You can change the target method handle and
by design the target method handle is not stored in a volatile field.
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.
Another solution is to not do the polling at each call but just increment
a counter and do the polling let say every 1000 calls.
If I finally decide to implement invalidation, I think I will implement it
like that.
bye blackdrag
cheers,
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.
