It's interesting that your example is one that would violate the JLS, at least
if done consistently, since the cached memory values might not be valid for the
type of the variable. Still, most of the problems I can see with this type of
system would be corrected by resetting the cache on every processor any time a
GC operation is done, and this would be required for any compliant JVM on such a
system in any case.
The model of out of order reads actually introduces more generality than is
required for modelling a system with per-processor caches which don't invalidate
on writes to memory (unless the hardware also reads blocks of memory at a time
into the cache, and the read block size is such that a single block can span
multiple objects - is this the case with the Alpha?). I'd think systems of this
type would have huge problems with Java in any case; each time a thread
performed a lock action the cache would need to be reset, and Java code tends to
contain a lot of lock actions. Or am I missing something here?
- Dennis
Bill Pugh wrote:
>
> >Hi Raymie,
> >
> >I'd like to understand more about the type of reordering operations you're
> >describing, and I assume I'm probably not the only one on the list who'd be
> >interested. Can you reference any online documentation or articles which
> >describe how this works? Or, alternatively, supply a more detailed
> >description
> >yourself?
> >
> >It's very counter-intuitive for me to hear about a processor that
> >can apparently
> >reorder operations to load data referenced off a pointer before it loads the
> >pointer, if I understand your remarks properly.
> >
> > - Dennis
>
> There are a couple of different formalisms for talking about memory
> models, as well as different ways of implementing them.
>
> One way to describe a memory model is to say that within a
> processor/thread, actions can be reordered according to some set of
> rules, and then the overall behavior must be as those the reordered
> actions were executed according to some global interleaving.
>
> But that is just a model. In reality, things don't happen atomically
> with regards to some global order. You have things like processors
> reading stale cache lines, reading old data that has been overwritten
> by another processor. It turns out that these more complicated
> situations can often be modelled by simpler, formal models.
>
> So here is what might really happen:
>
> Processor 2 has cached the contents of
> address 0x1234
>
> Processor 1 allocates a new
> object at address 0x1234
>
> Processor 1 initializes the
> object at address 0x1234
>
> Processor 1 does a memory
> barrier
>
> Processor 1 stores 0x1234
> into address 0x5678
>
> Processor 2 reads address 0x5678, gets
> 0x1234
>
> Processor 2 reads contents of object at address
> 0x1234 out of stale cache line
>
> This behavior can be modeled by allowing the read of address 0x1234
> to occur before the read of address 0x5678, even though the address
> 0x1234 is dependent on the value returned by reading address 0x5678.
>
> Bill Pugh
>
> -------------------------------
> This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
>
> To send a message to the list, email JavaMemoryModel@cs.umd.edu
> To send a request to the list, email majordomo@cs.umd.edu and put
> your request in the body of the message (use the request "help" for help).
> For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
-------------------------------
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email majordomo@cs.umd.edu and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:13 EDT