RFR: 8150084: Convert TraceMonitorMismatch to Unified Logging
Rachel Protacio
rachel.protacio at oracle.com
Fri Mar 25 18:18:10 UTC 2016
Hey, Max,
The code looks fine as-is, but perhaps could be optimized? Since all the
uses of monitormismatch call report_monitor_mismatch(), which has its
code in non-product only, you could remove the conditionals around it
and have the function declared with "PRODUCT_RETURN." Then, inside the
function you could put the "if log_is_enabled". So there will be less
compiled code in product mode. (This might also mean you could make the
monitormismatch tag "DEBUG_ONLY", but I'm not 100% sure about how that
works.)
Rachel
On 3/25/2016 1:28 PM, Max Ockner wrote:
> Hello,
> Please review another Unified Logging conversion.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8150084
> Webrev: http://cr.openjdk.java.net/~mockner/8150084.01/
>
> TraceMonitorMismatch has been converted to unified logging with
> monitormismatch tag and info level. There is very little output. To
> trigger the output, I ran a program which does a monitorenter without
> a monitorexit.
>
> 'java -XX:+TieredCompilation -Xcomp -Xlog:monitormismatch <program>'
>
> Tested with jtreg runtime tests and added MonitorMismatchTest.java to
> test for the output. The test body doesn't run on embedded since it
> uses TieredCompilation.
>
> If you search for TraceMonitorMismatch in the new source, you will
> find a bunch of instances in
> jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java.
> This file is a java implementation of GenerateOopMap.cpp and the two
> files aren't tied together in any way. This java level
> TraceMonitorMismatch flag is set to true in the code and doesn't get
> its value from the jvm level TraceMonitorMismatch flag. I have left
> these alone as another unfortunate naming coincidence.
>
> Thanks,
> Max
More information about the hotspot-runtime-dev
mailing list