What happens large number of Java objects are used for monitors ?

Thread view:

Meh-Lit Kim - 16 Aug 2005 21:58 GMT

Hi All,

Does any one know how a typical JVM (such as Sun's JVM) behaves when a
large number of Java objects are used for synchronization (i.e. monitor
objects) ?

Recall that, for example, in POSIX Threads, mutexes and conditional
variable synchronization objects are considered scarce resources.

So how would the JVM behave if I used, say, 30000+ Java objects as
monitors ?
What failures will be observed, if any ? Or will it take a longer time
to perform the locking primitives such as Object.notifyAll() ?

Also, does a typical JVM try to 'multiplex' Java object (monitors) on
to native synchronization primitives such as mutexes and conditional
variables ?

Thanks,
Meh-Lit, Kim

Reply to this Message

Andrew Thompson - 16 Aug 2005 22:04 GMT

> So how would the JVM behave if I used, say, 30000+ Java objects as
> monitors ?

Why not get back to us after you run a few (or even one) test(s)?

Signature

Andrew Thompson
physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
"Her voice was soft and cool, her eyes were clear and bright, ..but she's
not there"
The Zombies 'She's Not There'

Reply to this Message

Meh-Lit Kim - 18 Aug 2005 01:13 GMT

> > So how would the JVM behave if I used, say, 30000+ Java objects as
> > monitors ?
[quoted text clipped - 7 lines]
> not there"
> The Zombies 'She's Not There'

Hi,

I just did the following test:
created 20 custom thread instances, each thread instance containing
50,000 semaphores (implemented using Java's monitor mechanism).

When the threads are started, they do the following:
1. All threads will lock each of the 50,000 semaphores.
2. For even-numbered threads, wait 10 secs, then try to lock their
neighoring (odd-numbered) thread's 50,000 semaphores.
3. For odd-numbered threads, wait 30 secs, then unlock all of the
50,000 semaphores belonging to the thread.

Tested on Sun's JVM on win2k platform.

Observation:
All threads were able to lock and unlock the semaphores as expected and
no deadlock was observed.

Seem like the JVM will internally multiplex Java monitor objects on to
native synchronization primitives.

/Meh-Lit Kim

Reply to this Message

Mike Amling - 18 Aug 2005 19:58 GMT

> I just did the following test:
> created 20 custom thread instances, each thread instance containing
> 50,000 semaphores (implemented using Java's monitor mechanism).
>
> When the threads are started, they do the following:
> 1. All threads will lock each of the 50,000 semaphores.

What technique did you use to simultaneously synchronize on 50,000
distinct objects?

--Mike Amling

Reply to this Message

Mike Amling - 18 Aug 2005 20:43 GMT

>>>So how would the JVM behave if I used, say, 30000+ Java objects as
>>>monitors ?
[quoted text clipped - 18 lines]
> 2. For even-numbered threads, wait 10 secs, then try to lock their
> neighoring (odd-numbered) thread's 50,000 semaphores.

Many implementations use a low-overhead synchronization until there's
actually conflict. The low-overhead synchronization does not use an
operating-system serialization construct.
Since an even-numbered thread waits at the first conflict until the
one odd-numbered lock that it's waiting for is released, it sounds like
your method only exercised 10 locks at a time at the OS level.

> 3. For odd-numbered threads, wait 30 secs, then unlock all of the
> 50,000 semaphores belonging to the thread.

--Mike Amling

Reply to this Message

Matthias Ernst - 19 Aug 2005 07:15 GMT

> it sounds like
> your method only exercised 10 locks at a time at the OS level.

In general, there can only be as many contended monitors as there are threads
in the system; thus the number will more be around a few hundred at most.

Matthias

Reply to this Message

What happens large number of Java objects are used for monitors ?

Free Magazines