Bump :)
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. 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 > [1] https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D6747450&d=DwIDaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=BL4kVqghO4gn5XZF6vk60QTPyLdZ5Q0i- > YQhYV5AAXM&s=CRaeo9i-X27ZxNvgxD0IOJVROj6VpmLk5YINn7iJaVA&e= > > On 10/29/19 5:08 AM, Adam Farley8 wrote: > > Hey All, > > > > To restart (and re-centre) the chat on this: > > > > The issue I'm trying to solve is that it's hard to determine why a given > > class was not loaded by OpenJDK. > > > > The solution I proposed was additional (optional) debug output from the > > different classloaders. > > > > This way we can find out: > > > > - Whether any classloaders tried to load the class from your class' > > location (by displaying all locations they try to load the class from). > > - Which type of ClassLoaders tried to find your class. > > - Which classpath each ClassLoader tried to use. > > - Which modules were consulted. > > etc etc. > > > > Currently, it seems the only debug information available in this regard > > centres around: > > > > - Classes that were successfully loaded > > and > > - Exceptions when the class couldn't be loaded. > > > > So my questions are: > > > > 1) Am I trying to solve the right problem here? > > > > 2) Is there any support for this solution in principle, despite the fact > > that the webrev in its current form is...unrefined? > > > > 3) Is there a better way to get this information, with or without a code > > change? > > > > Advice or opinions are appreciated. > > > > > > Bug:https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232773&d=DwIDaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=BL4kVqghO4gn5XZF6vk60QTPyLdZ5Q0i- > YQhYV5AAXM&s=2uCIP9fqdKT2SmB0pjQXfhMGlAyZ9F-xdaW4Xp9elo4&e= > > > > Rough example webrev:https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8232773_webrev_&d=DwIDaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=BL4kVqghO4gn5XZF6vk60QTPyLdZ5Q0i- > YQhYV5AAXM&s=Il7T1mpLjlE5s1Yvy4qteJTKQ3l6o7THfwH6RaEuzF8&e= > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > > > > > > > From: David Holmes<david.hol...@oracle.com> > > To: Martin Buchholz<marti...@google.com> > > Cc: Ioi Lam<ioi....@oracle.com>, core-libs-dev > > <core-libs-dev@openjdk.java.net>, Adam Farley8<adam.far...@uk.ibm.com> > > Date: 24/10/2019 05:22 > > Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output > > for Specific Classes > > > > > > > > Hi Martin, > > > > This is going a bit OT I think ... > > > > On 24/10/2019 1:24 pm, Martin Buchholz wrote: > >> On Tue, Oct 22, 2019 at 3:58 PM David Holmes <david.hol...@oracle.com > >> <mailto:david.hol...@oracle.com>> wrote: > >> > >> > >> Perhaps one aspect of the class loading/resolution/initialization > >> process that can lead to confusion here is that if a class fails to > >> execute its static initialization then it is marked as Erroneous and > >> all > >> subsequent attempts to use that class result in NoClassDefFoundError > >> being thrown. If the original ExceptionInInitializerError got > > swallowed > >> somewhere then that can cause great confusion as to why the later > > NCDFE > >> occurs. The VM logging should help in that case - though I'd have to > >> confirm that (if it doesn't that should be fixed). > >> > >> > >> I had a need to debug an error in a <clinit> this week and was again > >> frustrated by the difficulty. > >> Classes falling into Erroneous state are rare so it seems reasonable to > >> save the exception as a cause for the subsequent NCDFE (probably can't > >> fix the misleading name of the exception) > > So as you know such a request existed: > > > > https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8048190&d=DwIDaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=AfL8IyQ5gm4a9cA4orx0EnUwiGqvG6rei- > DuA8gA0jQ&s=pzILDarpf9cN_MvQFqk1u3YZqFzSCRbBZVoRdFw4lS4&e= > > > > > > and was closed as it was considered that TraceExceptions (now > > -Xlog:exceptions) would provide the additional information. As noted in > > that bug there are also semantic issues about recording the cause of an > > exception in thread B, with an exception object that was thrown in > > thread A. So unless someone comes up with a very convincing argument, or > > else it prepared to do the work, I don't see that being re-opened. > > > >> I couldn't find a way to get hotspot to report the stack trace of all > >> exceptions that are thrown; -Xlog:exceptions=trace does not . > > -Xlog:exceptions shows where the exception is thrown and how it proceeds > > up the stack. It doesn't print the full stacktrace. That seems like a > > logging request for the Throwable constructor, or fillInStackTrace, to > > me, rather than trying to have the VM do it. IIRC we store minimal VM > > information in the backTrace which is expanded when needed into the full > > StacktraceElements array. > >> I was also frustrated that a StackOverflowError failed to report the > >> name of the thread and the stack size that was exceeded. But > >> -Xlog:threads*=trace helped there. > > The issue there is that SOE instances are allocated natively without > > executing any Java code (as we have run out of the Java stack) so we > > can't (easily) create a String message for the exception. However > > -Xlog:exceptions could be expanded to report that information at the > > point we throw the SOE. I filed - JDK-8232923. > > > > Cheers, > > David > > > > > > > > > > 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 > > > > 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
