Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > what is working memory and main memory?

Reply
Thread Tools

what is working memory and main memory?

 
 
Lee
Guest
Posts: n/a
 
      01-22-2004
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
 
Reply With Quote
 
 
 
 
Bryan Bullard
Guest
Posts: n/a
 
      01-22-2004

"Lee" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) 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
>



 
Reply With Quote
 
 
 
 
Doug Pardee
Guest
Posts: n/a
 
      01-23-2004
http://www.velocityreviews.com/forums/(E-Mail Removed) (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.
 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      01-23-2004
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



 
Reply With Quote
 
Lee
Guest
Posts: n/a
 
      01-23-2004
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

 
Reply With Quote
 
Lee
Guest
Posts: n/a
 
      01-23-2004
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.

 
Reply With Quote
 
Mark Thornton
Guest
Posts: n/a
 
      01-23-2004
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.

 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      01-24-2004
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



 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      01-24-2004
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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
how #define a main() function and call our own main function? ravi C Programming 28 09-26-2007 01:33 AM
adding main.aspx.vb & main.aspx.resx under aspx John M ASP .Net 1 05-29-2005 09:27 PM
Main > Popup > Popup > Close popup AND new URL in main? Jens Peter Hansen Javascript 7 06-19-2004 08:56 PM
int main(int argc, char *argv[] ) vs int main(int argc, char **argv ) Hal Styli C Programming 14 01-20-2004 10:00 PM



Advertisments