RFR: 8142506: Reimplement TraceClassUnloading with Unified Logging.

[David Holmes]

Hi Max,

I have not looked at the code :) This is more a meta-commentary on the 
general approach to conversion ...

On 12/11/2015 6:23 AM, Max Ockner wrote:
> Hello,
> Please review my change.
>
> Bug:  https://bugs.openjdk.java.net/browse/JDK-8142506
> Webrev:  http://cr.openjdk.java.net/~mockner/classunload/
>
> Testing:
> Hotspot jtreg tests with and without "-Xlog:classunload=trace"
> runthese tests with "-Xlog:classunload=trace"
> new jtreg test for classunload output.
>
> Summary:
>
> There are two parts to this fix.
>
> (1) Existing logic for TraceClassUnloading has been replaced with
> commands from Unified Logging.
>
> (2) Logging Alias Table. "-XX:+TraceClassUnloading" is now mapped to
> "-Xlog:classunload=debug" in the new logging alias table in
> arguments.cpp. Arguments are checked in the beginning of
> parse_each_vm_init_arg and if an argument (such as
> -XX:+TraceClassUnloading") is found in the alias table, the optionString
> is substituted for the value found in the logging alias table.
>
> I had to make a few decisions along that might raise questions, so I
> will knock a few of them out now.
>
> Why didn't I use the existing alias table?
> - Existing alias table only stores the flag name (TraceClassUnloading)
> and is meant for substituting one "-XX:" argument for another. This does
> not solve our problem.
>
> Why didn't I process the logging aliases later in
> parse_each_vm_init_arg, next to the rest of the "-XX:" argument processing?
> - The main processing for "-XX:" options happens after processing of
> "-Xlog" options. If we want the unified logging alias to be handled, it
> needs to be substituted in before "-Xlog:" is handled.
>
> Why does "-XX:+TraceClassUnloading" get aliased to
> "-Xlog:classunload=debug" and not "-Xlog:classunload=trace"?
> - logging statements that contained the develop-only flag "WizardMode"
> were converted to "-Xlog:classunload=trace". The logging statements that

I'm again having trouble reconciling the conversion of non-product 
logging into product logging. Really not sure it is desirable or useful.

More generally although most of our "tracing" flags start with Trace 
(some start with Print), that should be read simply as "log" or "report" 
in my opinion. So in the sense that the UL framework defines: info, 
debug, trace; it is certainly not the case that our "trace" flags should 
automatically map to a "trace" log level in the first instance. For 
something like classloading/unloading I would still expect to see basic 
information at the info level, more detailed info at the debug level, 
and so forth. So why are we not doing the basic class-unloading logging 
at the info level?

Thanks,
David


> could have been previously been triggered in Product mode are all now
> accessed by "-Xlog:classunload=debug". (We are updating logging, but we
> are not updating the functionality of the old logging options. Old
> options such as TraceClassUnloading are being aliased so they may
> continue to work in *exactly* the way they did before.)
>
> Thanks,
> Max
>