Limits on number of Locks/Monitors (a.k.a. java.lang.Object)

Discussion in 'Java' started by Meh-Lit Kim, Oct 7, 2003.

  1. Meh-Lit Kim

    Meh-Lit Kim Guest

    Hi all,

    I know that under Unix/Linux, there is a max number of
    synchronization objects (e.g. semaphores etc.) that one
    can create.

    I assume that likewise, there is a max number of mutexes
    and conditional vars that one can create in a threading
    environment such as when using Pthreads under Solaris.

    Now, each java Object provides the Monitor functionality,
    and I can easily create several thousand java.lang.Object(s)
    in the JVM given sufficient memory.

    Given the above, it seems that I can easily create more
    synchronization objects (java objects) than the underlying
    threading system supports in Java/JVM.

    Is this true ? If so, how does Java/JVM manage to accomplish this ?

    Please, someone drop me a clue!

    Meh-Lit Kim, Oct 7, 2003
    1. Advertisements

  2. Chris Uppal

    Chris Uppal Guest

    Meh-Lit Kim wrote:

    > Given the above, it seems that I can easily create more
    > synchronization objects (java objects) than the underlying
    > threading system supports in Java/JVM.

    Some techniques that could be used.

    Have an isLocked flag in the header of each object. Have a *single*
    system-wide OS-level mutex. Test, set and release the isLocked flags of all
    objects under the control of that OS mutex. You'd need to set up your own
    waiting queue(s) too, but that's just code...

    Generalise the above to have a pool of such mutexes (and queues). Chose a
    mutex for any object by -- say -- using the identityHash() of the object.
    This allows less contention in that each OS mutex is shared amongst fewer
    objects. I think early Sun JVMs did this.

    Another technique is to use "thin locks" (I first saw the term used by the IBM
    JVM people, I don't know if they invented it). This uses a few bits in the
    object header. In normal circumstances when an object is locked there is no
    need for a real Mutex because no other thread is going to access it anyway
    (think of all the serialized methods of StringBuffer that get used by "adding"
    strings, for instance). So in the easy case "locking" an object is just a
    test-and-set of a flag with a machine-specific instruction sequence that is
    thread-safe but does not involve expensive OS facilities. When a thread takes
    out a lock, if it finds that the lock is already by a different thread, then it
    "inflates" (again this is the word used by the IBM people) the lock into a real
    OS-level mutex (a "fat lock") and all *subsequent* synchronisation on that
    object will use the real mutex. Thus most synchronisation takes a fast path
    that is quick and light on OS resources. I think that both Sun and IBM (and
    probably others too) use this technique these days. See the literature from
    and Sun for more (and more correct) details.

    Of course these techniques could be combined.

    No doubt there are other techniques. E.g. the JVM implementation of threads
    be such that there is no need for OS-level mutexes at all.

    -- chris
    Chris Uppal, Oct 8, 2003
    1. Advertisements

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. jack
    Harald Hein
    Jul 1, 2003
  2. Harald Kirsch
    Harald Kirsch
    Aug 31, 2004
  3. JPractitioner
    Roedy Green
    Feb 24, 2006
  4. Replies:
  5. TsanChung
    Mark Space
    Aug 21, 2008

Share This Page