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.bate...@oracle.com> wrote on 22/10/2019 12:36:26:
> From: Alan Bateman <alan.bate...@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
