An AtomicReference is not going to outperform a volatile variable. So if a volatile variable is a no go, an atomic reference certainly is a no go.
And if there are multiple classes having their own class definitions, making all the new class definitions appears all at once, is going to be problematic. So if possible I would certainly look at how strict this behaviour needs to be. On Tue, Apr 20, 2010 at 6:30 PM, Brian Hurt <[email protected]> wrote: > > > 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. > -- 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.
