RFR(S): 8210514: Obsolete SyncVerbose

Daniel D. Daugherty daniel.daugherty at oracle.com
Fri Sep 7 21:30:24 UTC 2018


On 9/7/18 5:14 PM, Mikael Vidstedt wrote:
> Please review this change which obsoletes the SyncVerbose flag.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210514 <https://bugs.openjdk.java.net/browse/JDK-8210514>
> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210514/webrev.00/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8210514/webrev.00/open/webrev/>

src/hotspot/share/runtime/objectMonitor.cpp
     L1303:   if (SafepointMechanism::poll(Self)) {
         You don't want to drop the poll() call.

     There are also TEVENT macro calls that you can keep
     if you rewrite the macro to use logging instead.

src/hotspot/share/runtime/arguments.cpp
     No comments.

src/hotspot/share/runtime/globals.hpp
     No comments.

src/hotspot/share/runtime/objectMonitor.hpp
     Hmmm... I don't agree with this one....

     L325: #define TEVENT(nom) { if (SyncVerbose) FEVENT(nom); }
         I recommend changing the SyncVerbose into an is-logging-enabled
         check for a new monitor logging tag.

     L332:       tty->print_cr("INFO: " #nom " : %d", v);  \
         I recommend changing the print_cr() into a logging call.

     L333:       tty->flush();
         I don't think logging needs a flush.

src/hotspot/share/prims/jvmtiRawMonitor.cpp
src/hotspot/share/runtime/synchronizer.cpp
src/hotspot/share/runtime/thread.cpp
     These are all TEVENT macro calls that you can keep
     if you rewrite the macro to use logging instead.

Dan


>
> * Background (from bug)
>
> The experimental SyncVerbose flag can in theory be used to produce logging of some synchronization primitives. The flag was convenient when the synchronization implementation was implemented and tuned a long time ago.
>
> The SyncVerbose flag no longer serves the purpose it used to, and is "Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed.
>
>
> Testing: I’m running the normal tier1 testing (still in progress).
>
> Cheers,
> Mikael
>



More information about the hotspot-runtime-dev mailing list