RFR(S): 8217658 baseline_cleanups from Async Monitor Deflation project
David Holmes
david.holmes at oracle.com
Thu Jan 24 04:18:18 UTC 2019
Hi Dan,
This all seems fine. Some comments below.
One suggested addition to your cleanup :)
./share/runtime/basicLock.cpp
// [RGV] The next line appears to do nothing!
intptr_t dh = (intptr_t) displaced_header();
dest->set_displaced_header(displaced_header());
On 24/01/2019 6:07 am, Daniel D. Daugherty wrote:
> Greetings,
>
> I have a (S)mall patch extracted from the Async Monitor Deflation
> project that is ready for code review.
>
> The short version of what this patch is about:
>
> This sub-task captures updates to the baseline code that are not
> directly related to Async Monitor Deflation.
>
> The details are in the bug report:
>
> JDK-8217658 baseline_cleanups from Async Monitor Deflation project
> https://bugs.openjdk.java.net/browse/JDK-8217658
>
> Here's the webrev:
>
> http://cr.openjdk.java.net/~dcubed/8217658-webrev/0-for-jdk13/
To quote your main semantic changes from the bug report:
> - add missing "else" to logical if-else-statement in
> ObjectSynchronizer::get_lock_owner()
Okay - the two conditions are mutually exclusive.
> - guarantee that header() is NULL when
> ObjectSynchronizer::omRelease() is called
> - Replace a set_owner(NULL) call with a set_header(NULL)
> call in the "CASE: neutral" part of ObjectSynchronizer::inflate()
> when the object->cas_set_mark() fails. This is a rare race.
These seem okay but did get me thinking about the different roles of
ObjectMonitor::Recycle() and ObjectMonitor::clear() and the individual
clearing of fields! I find it all somewhat confusing - in particular why
clear() asserts that _header != NULL ! Some explanatory comments on
those methods would be appreciated at some point during this project.
Thanks,
David
-----
>
> This patch along with the other two patches for Async Monitor Deflation
> project have been through Mach5
> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3
> testing and I'm currently running my stress testing kits on my Linux-X64
> and Solaris-X64 servers.
>
> Thanks, in advance, for any questions, comments or suggestions.
>
> Dan
>
More information about the hotspot-runtime-dev
mailing list