Le 20/04/2010 10:19, Jochen Theodorou a écrit :
Hi all,
since quite a while I am looking for the best approach to tackle the
Groovy speed problem, but it seems I will not be able to fully solve
the problem without solving my concurrency problem.
My problem is more or less the following. A method call is done using
the data of a meta class, which is mostly like a caching structure,
that can be recreated unless certain conditions are met, that we don't
need to know for now. For each method call I need to check on this
meta class. And here part of the problem starts. How to get that object?
If it is stored in a volatile, ThreadLocal or even retrieved through a
data structure that uses synchornized, I get into problems with hotspot.
I found for me the ideal way to do this and other things would be to
be able to write an fully initialized object to main memory and other
threads can but don't have to get that value. They get knowledge of it
either as part of other synchronization, or by a user forced
instruction. The advantage is that does not have to happen on each
read, like with volatile. In theory ThreadLocal could be good enough,
if there were no speed issue. True ThreadLocal has been improved big
times over the years, but it is still slower as for example volatile,
because I cannot store the ThreadLocal object for long. So I would
still have to get a ThreadLocal for each method invocation and that is
bitter.
As I see it I can either use native code and maybe cause problems for
the JVM, or I am on a completely wrong track here and I simply see
something not.
So I am asking here for ideas. Anyone having one?
bye Jochen
Hi Jochen,
Sorry to not response earlier but I was on vacation
with only a really slow internet connection :(
and a prototype of new (JVM) language to finish :)
In my opinion, the only way to solve your problem
and the problem of all dynamic languages that have
mutable metaclass is to rely on invalidation.
This mechanism is not already implemented
in the reference implementation (JDK7)
but allows to optimistically avoid to do a
metaclass modification check at every call sites.
Instead of that the JSR292 API
provide a way to bulk invalidate some callsites (or all)
http://download.java.net/jdk7/docs/api/java/dyn/Linkage.html#invalidateAll%28%29
and force each invalidated callsite to re-query the bootstrap method
at the next invokedynamic.
For more details see
http://wiki.jvmlangsummit.com/DinnerAtPiatti
(search for section invalidation)
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.
