RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes

[Adam Farley8]

Hi Alan,

Thanks for the quick response.

Stewart, if you have a moment, could you please advise on the section with 
the @Stewart tag?

Alan Bateman <Alan.Bateman at oracle.com> wrote on 22/10/2019 12:36:26:

> From: Alan Bateman <Alan.Bateman at oracle.com>
...
> This looks very messy and I don't think is in any state to be reviewed. 

I'm sorry to hear that. The code was always meant as a very rough
draft to demonstrate what I had in mind, but your word choice there
tells me it's likely more "rough" than I had intended.

The thing that stands out the most, to me, are the ten two-layer 
single-line "IF" statements. The outer layer could be merged with the 
inner layer if I knew for sure that combining a static final boolean 
check with a non-static, non-final boolean check wouldn't discourage 
the JIT from optimising it away. Plus, some curly braces wouldn't hurt.

so this:

if (JDK_CL_VERBOSE)
    if (showClassLoading)
        ClassLoaderDiagnosticsHelper.doSomething();

Would become this:

if (JDK_CL_VERBOSE && showClassLoading) {
    ClassLoaderDiagnosticsHelper.doSomething();
}

I'd appreciate your thoughts on that, and while I appreciate that it would 

be unfair to expect you walk me though every problem in the code, it would
help me as a developer if you could bullet-point the biggest problems.

> When changing existing code it is important to respect the existing 
> coding conventions and keep the style as consistent as possible. Also we 

> should avoid adding new code in 2019 that uses Vector, StringTokenizer 
> and other legacy classes.

That's fair. If we do end up using some form of the Diagnostics Helper
class, I'll be sure to re-write it to exclude legacy classes.

> 
> That said, I think we do need to improve the serviceability and 
> diagnosability in the java.base module. This will become more important 
> as more of the runtime is developed in the libraries rather than in 
> libjvm. We have ad hoc logging in several areas, and one or two places 
> that emit JFR events, but don't have a consistent approach. Stuart Marks 

> lead a discussion on this at the OpenJDK workshop in August but it 
> didn't get any far. Maybe your needs may help that discussion to get 
> going again.

@Stuart ^

@Alan: I've added Stuart to this chain. Perhaps he could advise on the 
right way to address this issue. Whether we salvage this webrev or not, 
I feel we agree that more diagnostic information from the classloader 
would be beneficial.

> 
> For the issue at hand, maybe you could start by describing some of the 
> needs in the class loader areas. Is it mostly visibility issues? I see 
> the issue you created in JBS mentions "wrong version of a class" which 
> suggests you are interested in linkage errors too.
> 
> -Alan
> 

The primary need is to answer the following question for the everyman:

"Why isn't OpenJDK loading the class I want it to?"

By adding extra debugging to the ClassLoader, I hope to answer that
question for anyone who has that problem, regardless of the specific 
circumstance.

The bug was me attempting to flesh out that question, rather than a
strict list of contexts.

Hope that answers your question. :)

- Adam 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU