On Tue, Apr 20, 2010 at 4:19 AM, Jochen Theodorou <[email protected]> wrote:
> 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 > > Have you considered using java.util.concurrent.atomic.AtomicReference variables? I'm thinking of a design something like this: every object of a class has a reference to the AtomicReference that holds its class definition. All objects of the same class all point to the same AtomicReference (this is why there is a double indirection). Getting the current class definition compiles down into just two memory accesses- not perfect, but not bad. When the class definition is changed, the change updates the atomic reference, which updates all the classes simultaneously. I'm not sure what behavior you want, but something like this might work. Brian -- 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.
