RFR(s): 8073476: G1 logging ignores changes to PrintGC* flags via MXBeans
Bengt Rutisson
bengt.rutisson at oracle.com
Thu Apr 16 12:42:10 UTC 2015
Hello Dima,
On 2015-04-16 13:40, Dmitry Fazunenko wrote:
> Hello,
>
> Would you review a simple fix in G1.
>
> Short description:
> after introduction G1Log - dynamic changes of PrintGC and
> PrintGCDetails flag has no effect anymore, because G1Log looks for
> these flags during initialization only. The fix: sync the log level
> with the flags values.
>
> A huge thanks to Jesper who helped me a lot with my first product fix.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8073476
> Webrev: http://cr.openjdk.java.net/~dfazunen/8073476/webrev.06/
Sorry, but I don't really like the way this is solved. With this
approach calling G1GCPhaseTimes::print() suddenly has the side effect
that it resets the log level. That's quite unexpected for me. Especially
if you consider the code path in G1CollectedHeap::log_gc_footer() where
we do this:
void G1CollectedHeap::log_gc_footer(double pause_time_sec) {
if (!G1Log::fine()) {
return;
}
if (G1Log::finer()) {
...
g1_policy()->phase_times()->print(pause_time_sec);
...
}
If we don't have G1Log::fine() (which is PrintGC) enabled we will never
call the print() method and will thus not detect any changes made by the
MXBean. If we have G1Log::finer() enabled we enter the logging code,
print other things at the "finer" level (which is PrintGCDetails) and
then do the call to the print() method where we can suddenly decide that
PrintGCDetails no longer is enabled and not do the rest of the logging.
So for the same GC we will print some stuff at PrintGCDetails level and
some things at another level. Strange.
I would prefer to have a hook when the MXBean changes the value and only
update the level at that point.
Having said that I am not sure that this bug is worth fixing right now.
I am currently working on the JEP to make the GC logging use the new
unified logging format. That will change all of this and most likely
remove the G1Log class all together. So, my suggestion would be to leave
this as is for now and instead add the MXBean requirement to the unified
logging work.
Thanks,
Bengt
>
> Testing:
> I ran manually the test from the bug report to make sure the change
> fixes the problem.
> A regression test will be delivered separately as a fix of JDK-8077056
> <https://bugs.openjdk.java.net/browse/JDK-8077056>
>
> Thanks,
> Dima
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150416/ca9ed02f/attachment.htm>
More information about the hotspot-gc-dev
mailing list