Hi Mandy, Thanks for your thoughts. :)
I've asked around, and there don't appear to be any details regarding real-life customer scenarios that can be shared. I realise this doesn't exactly help my case. As for the volume of output, I hoped to address that via the inclusion of the regex check, thus allowing us to limit the output to things affecting the specific class, or group of classes. In any event, while this feature makes sense to me, I understand not every new idea gets to be a real boy. C'est la vie. Thanks for your time. :) Best Regards Adam Farley IBM Runtimes P.S. On a related note, if anyone more familiar with jcmd and Unified VM Logging wants to drop me some hints regarding getting the info in this issue's first bulleted list, it'd be appreciated. :) Issue: https://bugs.openjdk.java.net/browse/JDK-8232773 Mandy Chung <mandy.ch...@oracle.com> wrote on 06/01/2020 23:36:14: > From: Mandy Chung <mandy.ch...@oracle.com> > To: Adam Farley8 <adam.far...@uk.ibm.com> > Cc: core-libs-dev <core-libs-dev@openjdk.java.net> > Date: 06/01/2020 23:38 > Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output > for Specific Classes > > Hi Adam, > > Thanks for the examples. I was hoping for some customer issues and > how they identified the root causes to understand if there is any > specific problem to be considered than improving the overall class > loading diagnosability. > > The solution you propose is to add debug/trace statements in the > class loading implementation to improve diagnosability. I concern > the volume of trace output could make it hard to troubleshoot. > There are existing class loading traces with unified VM logging, JFR > events and also jcmd that also output class loading information. > Adding a new class loading tracing mechanism isn't a good option. > Alan mentioned that discussion at OpenJDK worshop [1] about > improving the serviceability and diagnosibility in the java.base > module. I think that'd better guide you if that makes further discussion. > > Mandy > [1] https://mail.openjdk.java.net/pipermail/workshop-discuss/2019- > August/000078.html > On 11/8/19 5:49 AM, Adam Farley8 wrote: > Hi Mandy, > > Sorry for the delay in responding. > > Mandy Chung <mandy.ch...@oracle.com> wrote on 29/10/2019 19:30:55: > > > From: Mandy Chung <mandy.ch...@oracle.com> > > To: Adam Farley8 <adam.far...@uk.ibm.com> > > Cc: core-libs-dev <core-libs-dev@openjdk.java.net> > > Date: 29/10/2019 19:31 > > Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output > > for Specific Classes > > > > Hi Adam, > > > > It'd be useful to provide a few typical scenarios that customers run into. > > > > That would give better understanding on the problem "hard to diagnose > > why a given class was not loaded" and help the consideration on > > alternatives. > > I'm happy to provide some hypothetical example scenarios, which I've > included below. We should note that this is not limited to customers, and > that this sort of diagnostic output is also extremely useful for people > helping customers to resolve issues. > > When a class cannot be found, it's a configuration issue and Class-Path hell > I've also included the way the webrev's debug output aids people trying > to reproduce this problem. > > Scenario 1: A user gets a ClassNotFoundException because the location > of the class is not on the classpath used by the ClassLoader/s that > attempted to load it, despite the fact that one ClassLoader definitely > has the location of the class on its classpath. > > Aid: This webrev's debug output tells the user, or the tech support > aiding the user: > - If the ClassLoader with the classpath location for that class is > ever tasked with trying to load that class. > - If the ClassLoader with the classpath location for that class > actually tries to load that class from the classpath (vs a module). > - If the ClassLoader with the classpath location actually checks that > location at all. > - What other ClassLoaders are used to attempt to load that class, > allowing the user/support agent to adjust the classpath for another > ClassLoader if needed. > > Scenario 2: A program uses the wrong version of a class. > > Aid: This webrev's debug output tells the user, or the tech support > aiding the user: > - Which classpath was used by the ClassLoader that loaded the class > at the time that the class was loaded. > - Which locations were checked by that ClassLoader before finding the > wrong version of the class. This, among other things, helps identify > access issues for the location of the correct class. > - Which ClassLoaders attempted to load the class, and in which order, > (increasingly useful in the current "nested" ClassLoading model). > > Scenario 3: A program is unable to find a class because none of the > ClassLoaders could find it, and you lack both familiarity with the > ClassLoader code, and the time to figure out how all of the different > ones work. > > Aid: This webrev's debug output tells the user, or the tech support > aiding the user: > - Which ClassLoaders were involved in each attempt to load the class. > - What the logic path was for each ClassLoader asked to load the > class. > - Which module/s, if any, were identified by the ClassLoader as the > potential owner/s of the class, and how that worked out in each > case. > > > The debug output could produce lots of trace output but > > the output does not clearly indicate the initiating class is. > > Correct. The scope of my debug output was limited to the actions > of the ClassLoader/s attempting to load a class that matches a > specific regex. > > > I wonder > > if the problem you are looking at is related to JDK-6747450 [1] or > > really tracing the class loader delegation and search path. > > The latter. If I implied that I was interested in the initiating class, > then I was wrong. Also, though I am not fundamentally opposed to > expanding the scope to incorporate JDK-6747450, the fact that it's been > drifting for nine years tells me I'd just be adding complexity without > adding anything that would support the inclusion of the change. > > Short version: I think this issue's scope should not include details > of the initiating class. > > > Or maybe > > Java Flight Recorder is a better candidate? > > I don't know much about Java Flight Recorder, as it currently only > supports one of the VMs I work with. > > > Without knowing specific > > of the problems customers have, perhaps VM logging can be enhanced to > > trace the initiating class and class loader? > > > > Mandy > > It's possible. I wouldn't know where to start with that. The simplest, > and most straight-forward approach (in my mind) is to add the debug > code directly to the code we're debugging. > > Plus, using a Class Library -based approach ensures that the debug > output is available regardless of the VM being used, or the user's > familiarity with Flight Recorder. > > Though this might just be a "me" problem. ;) > > What do you think? > > Best Regards > > Adam Farley 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
