RFR: 8210832: Remove sneaky locking in class Monitor
David Holmes
david.holmes at oracle.com
Wed Jan 30 07:29:50 UTC 2019
Hi Patricio,
<trimming>
First, thanks for all the many weeks of work you've put into this,
pulling together a number of ideas from different people to make it all
work!
I've only got a few minor comments/suggestions.
On 30/01/2019 10:24 am, Patricio Chilano wrote:
> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/
> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/
>
src/hotspot/share/runtime/interfaceSupport.inline.hpp
I'm very unclear how ThreadLockBlockInVM differs from ThreadBlockInVM.
You've duplicated a lot of complex code which is masking the actual
difference between the two wrappers to me. It seems to me that an extra
arg to transition_and_fence should allow you to handle the new behaviour
without having to duplicate so much of this code. In any case the
semantics of ThreadLockBlockInVM needs to be described.
Also I'm unclear what the "Lock" in ThreadLockBlockInVM actually refers
to. I find the name quite jarring to read.
On the subject of naming, do_preempt and preempt_by_safepoint don't
really convey to me what happens - what is being "preempted" here? I
would suggest a more direct Monitor::release_for_safepoint
---
Logging: why "nativemonitor"? The logging in mutex.cpp doesn't relate to
a "native" monitor?? Actually I'm not even sure if we need bother at all
with the one logging statement that is present.
---
src/hotspot/share/runtime/mutex.cpp
void Monitor::lock_without_safepoint_check(Thread * self) {
// Ensure that the Monitor does not require or allow safepoint checks.
The comment there should only say "not require".
void Monitor::preempt_by_safepoint() {
_lock.unlock();
}
Apart from renaming this as suggested above, aren't there any suitable
assertions we should have here? safepoint-in-progress or
handshake-in-progress? _owner == Thread::current?
Nit:
assert(_owner == Thread::current(), "should be equal: owner=" INTPTR_FORMAT
", self=" INTPTR_FORMAT, p2i(_owner),
p2i(Thread::current()));
with Dan's enhanced assertions there's an indentation issue. The second
line should indent to the first comma, but that will make the second
line extend way past 80 columns.
Also you could factor that assertion for _owner==Thread::current() into
its own function or macro to avoid the repetition.
OSThreadWaitState osts(self->osthread(), false /* not Object.wait() */);
This needs to be returned to its original place as per Dan's comments.
} else {
Monitor::lock(self);
}
You don't need Monitor:: here
// Temporary JVM_RawMonitor* support. A raw monitor can just be a
PlatformMonitor now.
This needs to be resolved before committing. Some of the existing
commentary on what raw monitors are needs to be retained. Not clear if
we need to set the _owner field or can just skip it.
Monitor::~Monitor() {
assert(_owner == NULL, "should be NULL: owner=" INTPTR_FORMAT,
p2i(_owner));
}
Will this automatically result in the PlatformMonitor destructor being
called?
---
Thanks,
David
-----
More information about the hotspot-dev
mailing list