On Apr 25, 2010, at 9:04 AM, Rémi Forax wrote:
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
Thanks for the notes Rémi. That is the sort of thing I was talking
about.
If there is an internal facility for interacting with safe-points or
global critical sections, I think it should be made available to other
languages, independent of call sites and method handles etc.
We all can do call sites, caches etc ourselves *today* with classes,
methods and code gen (as demonstrated by the backport and our various
language efforts). Yes, JSR-292 *might* simplify that, to the extent
our use cases align with its design. But I think it would be better to
simply make classes, methods and code gen cheaper and faster, with
universal benefit, than building method handles, invokedynamic etc and
putting a new burden on VMs to be able to implement and optimize them,
when they can already optimize method calls very well.
The thing we cannot do is the safe-point stuff, and, if we could, we
might be getting the same perf as Java, today, for our dynamic calls.
Rich
--
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.
