On Mar 12, 2014, at 10:23 PM, John Rose john.r.r...@oracle.com wrote:
P.S. FTR, I wish we could also remove the per-object monitor from its
privileged position, so not all objects are burdened by it, and other forms
of lock can be switched into the existing notation on a type-by-type basis.
On Mar 13, 2014, at 4:21 AM, Paul Sandoz paul.san...@oracle.com wrote:
On Mar 12, 2014, at 10:23 PM, John Rose john.r.r...@oracle.com wrote:
P.S. FTR, I wish we could also remove the per-object monitor from its
privileged position, so not all objects are burdened by it, and other forms
of
On Feb 28, 2014, at 10:11 PM, John Rose john.r.r...@oracle.com wrote:
On Feb 28, 2014, at 1:38 AM, Paul Sandoz paul.san...@oracle.com wrote:
But chances are, the day after I take it off, I will need it.
tryMonitorEnter() does no harm and it is out of reach of most programmers.
I think
On Mar 5, 2014, at 3:04 PM, Doug Lea d...@cs.oswego.edu wrote:
A few comments on catching up with this discussion...
Same here, back from a holiday last week.
tryMonitorEnter() does no harm and it is out of reach of most
programmers.
Built-in monitors are heavily optimized for typical
I think that we've covered all the angles, and that we can remove it.
– John
On Mar 12, 2014, at 1:44 PM, Paul Sandoz paul.san...@oracle.com wrote:
Currently i cannot find any external uses of it.
P.S. FTR, I wish we could also remove the per-object monitor from its
privileged position, so not all objects are burdened by it, and other forms of
lock can be switched into the existing notation on a type-by-type basis. This
is obviously a long, long term wish. A starting point is a notion of
On 04/03/2014 15:32, David M. Lloyd wrote:
On 03/03/2014 09:45 PM, David Holmes wrote:
We should not introduce anything that allows something that was
guaranteed to be safe by the language, to become unsafe.
Define 'safe'. Because I don't think it's unsafe, any more than
I believe even
On 03/06/2014 08:48 AM, Tom Hawtin wrote:
On 04/03/2014 15:32, David M. Lloyd wrote:
On 03/03/2014 09:45 PM, David Holmes wrote:
We should not introduce anything that allows something that was
guaranteed to be safe by the language, to become unsafe.
Define 'safe'. Because I don't think
A few comments on catching up with this discussion...
tryMonitorEnter() does no harm and it is out of reach of most
programmers.
Built-in monitors are heavily optimized for typical cases,
which does not include any form of tryLock. So the hotspot
implementation of tryMonitorEnter is very
On 03/03/2014 09:45 PM, David Holmes wrote:
On 3/03/2014 10:56 PM, David M. Lloyd wrote:
Yes, that would necessarily be the contract of a Monitors class, just as
it is part of the contract of Lock today. If your argument is that it
shouldn't be allowed because it might be used wrong, we might
On 5/03/2014 1:32 AM, David M. Lloyd wrote:
On 03/03/2014 09:45 PM, David Holmes wrote:
On 3/03/2014 10:56 PM, David M. Lloyd wrote:
Yes, that would necessarily be the contract of a Monitors class, just as
it is part of the contract of Lock today. If your argument is that it
shouldn't be
On Mar 4, 2014, at 7:41 PM, David Holmes david.hol...@oracle.com wrote:
I agree it is as unsafe as using Lock. I think not being able to forget to
unlock a monitor is more than just convenient. YMMV and obviously does.
That's why that unsafe kind of stuff currently lives in class unsafe.
On 27/02/2014 11:56 PM, Vitaly Davidovich wrote:
Right, there's no such guarantee/requirement. JVMS mentions that
implementations are permitted to enforce balance (called structured locking
there) but not required:
http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html#jvms-2.11.10
And
Yes, that would necessarily be the contract of a Monitors class, just as
it is part of the contract of Lock today. If your argument is that it
shouldn't be allowed because it might be used wrong, we might as well
just delete most of the JDK, ReentrantLock included, since it suffers
from the
On 02/27/2014 06:38 AM, David Holmes wrote:
On 27/02/2014 9:12 PM, Stephen Colebourne wrote:
On 26 February 2014 20:54, Martin Buchholz marti...@google.com wrote:
It does seem that being able to tell whether a java object monitor is
currently locked is useful for debugging and monitoring -
On 3/03/2014 10:56 PM, David M. Lloyd wrote:
Yes, that would necessarily be the contract of a Monitors class, just as
it is part of the contract of Lock today. If your argument is that it
shouldn't be allowed because it might be used wrong, we might as well
just delete most of the JDK,
On 3/03/2014 10:57 PM, David M. Lloyd wrote:
On 02/27/2014 06:38 AM, David Holmes wrote:
On 27/02/2014 9:12 PM, Stephen Colebourne wrote:
On 26 February 2014 20:54, Martin Buchholz marti...@google.com wrote:
It does seem that being able to tell whether a java object monitor is
currently
On 4/03/2014 1:45 PM, David Holmes wrote:
On 3/03/2014 10:56 PM, David M. Lloyd wrote:
Yes, that would necessarily be the contract of a Monitors class, just as
it is part of the contract of Lock today. If your argument is that it
shouldn't be allowed because it might be used wrong, we might as
On 04/03/2014, David Holmes david.hol...@oracle.com wrote:
On 3/03/2014 10:56 PM, David M. Lloyd wrote:
Yes, that would necessarily be the contract of a Monitors class, just as
it is part of the contract of Lock today. If your argument is that it
shouldn't be allowed because it might be used
On 03/04/2014 05:09 AM, David Holmes wrote:
On 4/03/2014 1:45 PM, David Holmes wrote:
On 3/03/2014 10:56 PM, David M. Lloyd wrote:
Yes, that would necessarily be the contract of a Monitors class,
just as
it is part of the contract of Lock today. If your argument is that it
shouldn't be
On 03/04/2014 08:01 AM, Peter Levart wrote:
On 03/04/2014 05:09 AM, David Holmes wrote:
On 4/03/2014 1:45 PM, David Holmes wrote:
On 3/03/2014 10:56 PM, David M. Lloyd wrote:
Yes, that would necessarily be the contract of a Monitors class,
just as
it is part of the contract of Lock today.
With a curious 9 months old crawling around the house, I've just moved
the sharp knives to the top draw in the kitchen - out of reach. I don't
think we should be encouraging people to use monitor.tryLock() for
various reasons:
1. We have a richer interface with Lock/ReentrantLock, including
Making the language Kindergarten-friendly at the cost of general
usefulness is a mistake, IMO. And anyway there's nothing that is less
safe about a Monitors class than ReentrantLock; on the other hand,
monitors continue to be considerably lighter (size and (for most of the
history of JUC)
On Feb 27, 2014, at 3:51 PM, Dr Heinz M. Kabutz he...@javaspecialists.eu
wrote:
I have never used this in the wild, but rather have moved over to the
ReentrantLock when I needed that particular functionality.
However, I do see a place for this ability. As I wrote in here:
On Feb 28, 2014, at 1:38 AM, Paul Sandoz paul.san...@oracle.com wrote:
But chances are, the day after I take it off, I will need it.
tryMonitorEnter() does no harm and it is out of reach of most programmers.
I think your analogy to a spare wheel is misleading. Continuing with the car
Except that Lock has features that are not supported by intrinsic locks
(timed wait, interruptible wait.) So the Lock returned would not
conform to Lock's contract, and attempting to call these methods would
probably throw UOE.
On 2/27/2014 6:12 AM, Stephen Colebourne wrote:
On 26 February
On 02/27/2014 08:41 AM, David Holmes wrote:
On 27/02/2014 5:30 PM, Peter Levart wrote:
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
On 27/02/2014 6:38 PM, Peter Levart wrote:
On 02/27/2014 08:41 AM, David Holmes wrote:
On 27/02/2014 5:30 PM, Peter Levart wrote:
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
On Feb 26, 2014, at 7:10 PM, Brian Goetz brian.go...@oracle.com wrote:
Seems like a symbolic victory, at least :)
I'll take what ever small victory i can with this beast of a class :-)
It's less unsafe than some unsafe methods (you can use it to create a DoS but
not to violate safety
On 26 February 2014 20:54, Martin Buchholz marti...@google.com wrote:
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.
Perhaps it would be useful to be able to expose a java object
On 02/27/2014 10:58 AM, David Holmes wrote:
On 27/02/2014 6:38 PM, Peter Levart wrote:
On 02/27/2014 08:41 AM, David Holmes wrote:
On 27/02/2014 5:30 PM, Peter Levart wrote:
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
On Feb 27, 2014, at 12:52 PM, Peter Levart peter.lev...@gmail.com wrote:
Ok, then what about the following:
static boolean isLocked(final Object monitor, final long millis) throws
InterruptedException {
return new Thread() {
volatile boolean unlocked;
On 27/02/2014 9:12 PM, Stephen Colebourne wrote:
On 26 February 2014 20:54, Martin Buchholz marti...@google.com wrote:
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.
Perhaps it
David Holmes wrote:
I don't think this is workable. Exposing a monitor as Lock would allow
you to break the guarantees/requirements involving balanced-locking for
monitors.
Where are these guarantees/requirements documented?
Regards,
Jeroen
Right, there's no such guarantee/requirement. JVMS mentions that
implementations are permitted to enforce balance (called structured locking
there) but not required:
http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html#jvms-2.11.10
Thanks
Sent from my phone
On Feb 27, 2014 8:40 AM,
This is actually a somewhat unfortunate feature. Had this not been in
place, I could have just used custom bytecodes to perform the lock magic
that I ended up using Unsafe for (I'm the guy that wrote JBoss Modules,
i.e. apparently the one usage in the wild of these methods).
The restriction
I have never used this in the wild, but rather have moved over to the
ReentrantLock when I needed that particular functionality.
However, I do see a place for this ability. As I wrote in here:
http://www.javaspecialists.eu/archive/Issue194.html - sometimes you need
to modify code that is
A Monitors class could possibly be introduced which simply has three
(intrinsic) static methods: void lock(Object obj), void unlock(Object
obj), boolean tryLock(Object obj).
Could even add a void lockInterruptibly(Object obj) throws
InterruptedException.
Why not? Monitors are not going
Hi David,
On Feb 27, 2014, at 3:24 PM, David M. Lloyd david.ll...@redhat.com wrote:
(I'm the guy that wrote JBoss Modules, i.e. apparently the one usage in the
wild of these methods).
Yes :-) the only one i have found so far.
IIUC JBoss Modules only needs to use those methods on Java 1.6,
Plus, monitors can get optimized beautifully when there is no
contention, although that falls away for the code that uses
monitorEnter/monitorExit calls directly as far as I could tell.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of The Java(tm) Specialists' Newsletter
Oracle
On 02/27/2014 11:36 AM, Paul Sandoz wrote:
Hi David,
On Feb 27, 2014, at 3:24 PM, David M. Lloyd david.ll...@redhat.com wrote:
(I'm the guy that wrote JBoss Modules, i.e. apparently the one usage in the
wild of these methods).
Yes :-) the only one i have found so far.
IIUC JBoss Modules
On 2/27/14 4:29 AM, Paul Sandoz wrote:
This will allocate about 10 Thread objects per second until the other thread
finally reaches the synchronized read() method in BufferedInputStream...
I like it.
I like it too.
I do have a slight preference for Mandy's solution, see below, but i am not
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
Seems like a symbolic victory, at least :) It's less unsafe than some
unsafe methods (you can use it to create a DoS but not to violate safety
constraints like bounds checking or pointer casting) but its a start!
On 2/26/2014 10:12 AM, Paul Sandoz wrote:
Hi,
Out of all the methods on Unsafe
On 2/26/2014 12: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
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
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
On 27/02/2014 5:30 PM, Peter Levart wrote:
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
48 matches
Mail list logo
