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
--
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.
