what is working memory and main memory?

Discussion in 'Java' started by Lee, Jan 22, 2004.

  1. Lee

    Lee Guest

    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, Jan 22, 2004
    #1
    1. Advertising

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

    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
    >
     
    Bryan Bullard, Jan 22, 2004
    #2
    1. Advertising

  3. Lee

    Doug Pardee Guest

    (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, Jan 23, 2004
    #3
  4. Lee

    Chris Uppal Guest

    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
     
    Chris Uppal, Jan 23, 2004
    #4
  5. Lee

    Lee Guest

    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
     
    Lee, Jan 23, 2004
    #5
  6. Lee

    Lee Guest

    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.
     
    Lee, Jan 23, 2004
    #6
  7. 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.
     
    Mark Thornton, Jan 23, 2004
    #7
  8. Lee

    Chris Uppal Guest

    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
     
    Chris Uppal, Jan 24, 2004
    #8
  9. Lee

    Chris Uppal Guest

    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
     
    Chris Uppal, Jan 24, 2004
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John M
    Replies:
    1
    Views:
    1,186
    Kumar Reddi
    May 29, 2005
  2. Hal Styli
    Replies:
    14
    Views:
    1,646
    Old Wolf
    Jan 20, 2004
  3. Frederick Ding

    int main() or int main(void)?

    Frederick Ding, Dec 3, 2005, in forum: C Programming
    Replies:
    10
    Views:
    653
  4. ravi
    Replies:
    28
    Views:
    983
    Richard Heathfield
    Sep 26, 2007
  5. Jens Peter Hansen
    Replies:
    7
    Views:
    544
    Randy Webb
    Jun 19, 2004
Loading...

Share This Page