On 02/27/2014 08:29 AM, Peter Levart wrote:
On 02/26/2014 09:54 PM, Martin Buchholz wrote:
I don't recall having added this particular wart
to test/java/lang/ProcessBuilder/Basic.java, and history suggests that
others did that.
It does seem that being able to tell whether a java object monitor is
currently locked is useful for debugging and monitoring - there
should be a
way to do that.
Thread.holdsLock(Object) ?
Ah, you meant to query from some other thread, right?
Peter
Regards, Peter
On Wed, Feb 26, 2014 at 7:12 AM, Paul Sandoz <paul.san...@oracle.com>
wrote:
Hi,
Out of all the methods on Unsafe i think the
monitorEnter/monitorExit/tryMonitorEnter are the least used and are
very
strong candidates for removal.
99% of use-cases are supported by classes in the
java.util.concurrent.locks package.
Within the JDK itself it is only used in one JDK test file
test/java/lang/ProcessBuilder/Basic.java:
while (unsafe.tryMonitorEnter(s)) {
unsafe.monitorExit(s);
Thread.sleep(1);
}
for a test verifying an EOF is received on pending reads and it is
polling
to check when the process builder acquires the lock before
destroying the
process, presumably to avoid some sort of race condition that
occasionally
causes the test to fail.
I believe this test as been through a number of rounds, i stared at
things
for a bit, but cannot quickly work out a replacement; i lack the
knowledge
on this area.
Outside of the JDK i can only find one usage of monitorExit/Enter
(according to grep code) in JBoss modules, and i believe this is
only used
on Java 1.6 to work around some limitations in class loading that were
fixed in 1.7.
Given such very limited use i propose to remove these methods after
having
worked out a fix for ProcessBuilder/Basic.java test.
Paul.
