> -----Original Message----- > From: Jeff Clites [mailto:[EMAIL PROTECTED] > Sent: Thursday January 15, 2004 01:28 > To: Gordon Henriksen > Cc: [EMAIL PROTECTED] > Subject: Re: JVM as a threading example (threads proposal) > > > On Jan 12, 2004, at 10:03 AM, Gordon Henriksen wrote: > > > On Monday, January 12, 2004, at 04:29 , Jeff Clites wrote: > > > >> 5) Java seems to use a check-in/check-out model for access > to global > >> data, in which global data "lives" in a central store, but > is copied > >> back-and-forth to thread-local storage for modification. I don't > >> fully understand the performance benefit which I assume this > >> provides, but this is something else we need to understand. It's > >> discussed in detail in the threads section of the JVM spec, > >> <http://java.sun.com/docs/books/vmspec/2nd-edition/html/ > >> Threads.doc.html>. > > > > The passage in question being: > > > > Every thread has a working memory in which it keeps its own working > > copy of variables that it must use or assign. As the thread > executes a > > program, it operates on these working copies. The main > memory contains > > the master copy of every variable. There are rules about > when a thread > > is permitted or required to transfer the contents of its > working copy > > of a variable into the master copy or vice versa. > > There's that passage, but actually the following sections go > into depth > about the semantic constraints on how this is supposed to work. > > > This is very obliquely phrased, but it refers to the > register file and > > stack frame. Or, since the Java bytecode is stack-based, it > refers to > > the stack. > > You might be right, but that's not exactly how I read it, > because later > it says, "A use action (by a thread) transfers the contents of the > thread's working copy of a variable to the thread's execution engine. > This action is performed whenever a thread executes a virtual machine > instruction that uses the value of a variable." > > I assume that the stack would correspond to the "execution engine" > here, rather than to the "thread's working copy", but I could read it > either way. > > In any case, I thought this sounded like an interesting model, but > based on the rules in that section about how accesses to data in the > thread-local store have to correspond to accesses of the main > store, it > wasn't apparent to me how there was an advantage over just accessing > things directly out of the main store. But I assume I'm overlooking > some subtlety, and that there may be an idea here that we > could use to > our advantage.
The two-level memory model in the spec seems to address, as a group, the register file, stack (JVM stack and/or system call stack; same difference), and the cache hierarchy in an SMP system. All in all, it's a very oblique way of saying that changes might not be immediately visible to all threads. For example, on the PPC, a "sync" instruction is required to ensure that all the processor caches have a consistent view of main memory. sync and its equivalents are far too expensive to execute after every change to any variable, so the JVM's spec is written to allow implementations to avoid it most of the time. -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
