> 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.
I'm not sure I'm clear on the ownership of the metadata. If Thread-A modifies the metadata, must this be "immediately" visible to Thread-B (and C and D...)? If the meta data is, essentially, global across threads, then any change made by one thread has to be propagated (flushed) back to main memory and then pulled back up into the thread/CPU local cache, using write and read barriers, if I understand correctly. I don't know any way around that; conceptually, as I understand it, individual threads and cores may/will have their own local, detached copy of whatever they need from main memory. At some point that copy and the later re-synchronization has to take place. That sort of data sharing--having a consistent view of mutable state across threads--is simply expensive on some level (for some value of expensive). If the given metadata is considered fixed/static for the execution of a thread, and you don't want the cost of a thread local, then you could probably weave it into the stack as a (to the user, hidden) method parameter, no? Then you would avoid the indirection of the thread local lookup. In the end, I think of a TL as a way to access data across method calls within a single thread of execution when the value is not available on the stack, like a "thread global" variable (haha). If you're actually writing the compiler, though, you might be able to do this sort of extension of the parameter list automatically. Patrick -- 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.
