«

Hello,

I have searched all java groups and I can not get understanding on
working memory on a JVM. What is _working memory_ after all? The
concept is only briefly discussed in Chapter 8: Threads and Locks.
But I have not found much useful info in 3.5 Runtime Data Area. I
have browsed some open source JVM implementation, still can not find
how the working memory works?

I guess the working memory is a logical local cache built on top of
the heap shared by all threads. It is just a per-thread memory area.
JVM uses it to avoid the shared area accesses synchronization
inefficiency. So basically you have two copies of objects, one in
shared area, the other in the per-thread memory area. Is it correct?

Cheers,

Lee

"Lee" <> wrote in message
news: om...

working memory possibly refers to the "working set", which has to more with
the underlying system and really nothing to do with java. a "working set"
is memory that is committed to a running process. for more info google for
"copy on write" or "virtual memory."

perhaps someone will have something to add or rebuttal.

bryan


> Hello,
>
> I have searched all java groups and I can not get understanding on
> working memory on a JVM. What is _working memory_ after all? The
> concept is only briefly discussed in Chapter 8: Threads and Locks.
> But I have not found much useful info in 3.5 Runtime Data Area. I
> have browsed some open source JVM implementation, still can not find
> how the working memory works?
>
> I guess the working memory is a logical local cache built on top of
> the heap shared by all threads. It is just a per-thread memory area.
> JVM uses it to avoid the shared area accesses synchronization
> inefficiency. So basically you have two copies of objects, one in
> shared area, the other in the per-thread memory area. Is it correct?
>
> Cheers,
>
> Lee
>

(Lee) wrote:
> I have searched all java groups and I can not get understanding on
> working memory on a JVM. What is _working memory_ after all? The
> concept is only briefly discussed in Chapter 8: Threads and Locks.
> But I have not found much useful info in 3.5 Runtime Data Area. I
> have browsed some open source JVM implementation, still can not find
> how the working memory works?

Per the Java2 Language Specification, section 17.1 (Terminology and
Framework):
"Variables are kept in a *main memory* that is shared by all
threads..."
"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..."

Essentially, "working memory" means any memory that a thread is using
which is NOT guaranteed to be fully and synchronously shared with
other threads.

In practice, this would include L1 and L2 hardware caches, CPU
registers, CPU stack data, Java stack data, and any other temporary
storage being used by a thread.

When running in a multi-CPU system, this stuff is REALLY important.

Doug Pardee wrote:

> Essentially, "working memory" means any memory that a thread is using
> which is NOT guaranteed to be fully and synchronously shared with
> other threads.
>
> In practice, this would include L1 and L2 hardware caches, CPU
> registers, CPU stack data, Java stack data, and any other temporary
> storage being used by a thread.

I think the word there should be "might" not "would" -- it depends on the
machine architecture.

E.g. IIRC (doubtful -- so don't take this as gospel) a multi-CPU i86 machine
synchronises (by default) the even the L1 caches across CPUs. Whether my
memory is correct in this is -- in a sense -- immaterial; what matters is that
it *might* do such synchronisation.

OTOH, I get the impression that Sun's big iron can run in a mode where
different CPU's can have out-of-synch views of what most of us would think of
as "main memory". So that for instance if two threads are looking at a big
array of bytes (in "main memory" not "stack"), and one loops over it setting
all the values to 1, then the other thread's view of that array is
indeterminate -- it may see the array still unset, or it may see some random
"blocks" of the array set and others not. Again, my impression of how the Sun
machines work may be wrong, but the important point is that the Java threading
semantics is designed to allow for machines that *do* work like that.

-- chris

I am afraid the working set concept in OS is a little different than
working memory metioned in JVM. Working set can be regarded as a set
of pages committed to a process. Note the shared memory is mapped
into multiple process address spaces. Working set is composed of
committed pages, shared or not does not matter. In java, the working
memory is separated from the shared memory (main memory). I assume
the motive is to reduce sync requirement for multi-thread accesses.
Do we have shared heap and per-thread heaps? This concept is pretty
vague in the Spec.

Cheers.

Lee


> working memory possibly refers to the "working set", which has to more with
> the underlying system and really nothing to do with java. a "working set"
> is memory that is committed to a running process. for more info google for
> "copy on write" or "virtual memory."
>
> perhaps someone will have something to add or rebuttal.
>
> bryan

If it means simply cache, whether it is on-board, on-chip, or
whatever, it means little to us software engineers. As the
consistency is often implemented by hardware, for instance snooping
mechanism. In that case, I guess the working memory merely means the
cpu register file which holds temp copies of some memory locations for
efficiency. Working memory=cpu regs, main memory=RAM in common sense,
Or something else?


What you are talking about SMP is memory barrier, or weak memory
ordering if I understand it correctly. Different CPU may have
different observation on a same executation path. You assign var A,
followed by B, I may see the opposite order. If, as you suggest,
working memory function is the same as memory barrier, then does it
imply the working memory is the store unit on the CPU?

Seems your argument is working memory is very close to the chip metal.

Lee


> Doug Pardee wrote:
>
> > Essentially, "working memory" means any memory that a thread is using
> > which is NOT guaranteed to be fully and synchronously shared with
> > other threads.
> >
> > In practice, this would include L1 and L2 hardware caches, CPU
> > registers, CPU stack data, Java stack data, and any other temporary
> > storage being used by a thread.
>
> I think the word there should be "might" not "would" -- it depends on the
> machine architecture.
>
> E.g. IIRC (doubtful -- so don't take this as gospel) a multi-CPU i86 machine
> synchronises (by default) the even the L1 caches across CPUs. Whether my
> memory is correct in this is -- in a sense -- immaterial; what matters is that
> it *might* do such synchronisation.


> OTOH, I get the impression that Sun's big iron can run in a mode where
> different CPU's can have out-of-synch views of what most of us would think of
> as "main memory". So that for instance if two threads are looking at a big
> array of bytes (in "main memory" not "stack"), and one loops over it setting
> all the values to 1, then the other thread's view of that array is
> indeterminate -- it may see the array still unset, or it may see some random
> "blocks" of the array set and others not. Again, my impression of how the Sun
> machines work may be wrong, but the important point is that the Java threading
> semantics is designed to allow for machines that *do* work like that.

Chris Uppal wrote:

> OTOH, I get the impression that Sun's big iron can run in a mode where
> different CPU's can have out-of-synch views of what most of us would think of
> as "main memory". So that for instance if two threads are looking at a big
> array of bytes (in "main memory" not "stack"), and one loops over it setting
> all the values to 1, then the other thread's view of that array is
> indeterminate -- it may see the array still unset, or it may see some random
> "blocks" of the array set and others not. Again, my impression of how the Sun
> machines work may be wrong, but the important point is that the Java threading
> semantics is designed to allow for machines that *do* work like that.
>

I believe that some Sparc systems can have the memory mode configured.
However the weakest of the modes available is never used because too
much (C/C++) software breaks.

Lee wrote:

> If it means simply cache, whether it is on-board, on-chip, or
> whatever, it means little to us software engineers. As the
> consistency is often implemented by hardware, for instance snooping
> mechanism.

But the point is that the "cache consistency mechanism" *may* require
cooperation from software (i.e it's faster to run with less consistency if the
software can tell you when you can get away with it). The Java
thread/synchronisation mechanism is specified with that in mind. It *does not*
require consistency except though use of the 'synchronized' keyword (and
'volatile' -- though that's not a lot of use for anything except primitive
types), which is why the Java runtime software has "enough information" to be
able to co-operate actively with the hardware to maintain the appearance of
consistency without forcing the re-synchronisation of memory before every
instruction.

So. if we are writing threaded Java and intend it to be *correct* Java, rather
than just "well it works on my box, it must be OK", then we software engineers
do indeed have to care about these issues. Java is spec-ed *not* to require
that the hardware does all the work for us.


> What you are talking about SMP is memory barrier, or weak memory
> ordering if I understand it correctly. Different CPU may have
> different observation on a same executation path. You assign var A,
> followed by B, I may see the opposite order. If, as you suggest,
> working memory function is the same as memory barrier, then does it
> imply the working memory is the store unit on the CPU?

No. (or, actually, "Yes probably, but".) It's an *abstraction* that is
designed to *allow* such implementations with loose coupling between each CPU
and shared main memory.


> Seems your argument is working memory is very close to the chip metal.

Rather the reverse, I'd say. The point of Sun's spec is to get as far away as
possible from over-constraining the implementation in terms of the metal. But,
yes, I think it's an abstraction that would have been unlikely to occur to
anyone without specific experience of loosely-coupled SMP, so in that sense it
reflects close-to-the metal thinking.

-- chris

Mark Thornton wrote:

> I believe that some Sparc systems can have the memory mode configured.
> However the weakest of the modes available is never used because too
> much (C/C++) software breaks.

That figures.

It'd be interesting to know whether Java implementations can *actually* make
use of such modes. Whether they derive useful benefit from it for (at least
some) real applications, and whether enough Java code is written without
incorrect assumptions about the hardware.


-- chris