Hi Andrew, thanks for giving this advice! It confirms the problems I see.
For the context: I proposed better NPE exception messages: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/ The original implementation is C++ and walks the metaspace given the method* and BCI where the exception occurred. So it uses only data already sitting in memory. See JVM_GetExtendedNPEMessage() in jvm.cpp. The idea was to implement this in Java using StackWalker and ASM. If I had the right bytecodes, and the right starting point, ASM would be helpful to implement the analysis I think. I'll look some more into the reconstituter code... Thanks, Goetz. > -----Original Message----- > From: Andrew Dinn <ad...@redhat.com> > Sent: Mittwoch, 20. Februar 2019 18:29 > To: Lindenmaier, Goetz <goetz.lindenma...@sap.com> > Cc: core-libs-dev <core-libs-dev@openjdk.java.net>; hotspot-runtime- > d...@openjdk.java.net > Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException > describing what is null. > > Hi Goetz, > > Forgive me for jumping in here and, possibly, misunderstanding what you > want -- I may have misunderstood what you are trying to do as I have not > been following this thread carefully. > > On 20/02/2019 16:36, Lindenmaier, Goetz wrote: > > 1. As I understand, it would be simple to extend ASM to deliver the initial > > BCIs when the stream is parsed. They could be stored separately and > > discarded once something gets modified (similar to InsnList.cache). > > Non-method bytecodes are normally dropped by the JVM during parsing. > Only method bytecode is retained in the metadata model. One exception is > when a registered ClassFileTransformer changes the loaded bytecode at > load time. The original bytecode for the class is saved when that happens. > > Note that retaining method bytecode does not imply retaining the > original classpool in bytecode format. Indices into the classpool are > interpreted as indices into a metadata version of the classpool. Amongst > other things, that allows sharing of symbols that occur in more than one > class files. This avoids a /vast/ amount of storage costs. > > > 2. Is there any possibility to access the live datastructures/bytecode in > > the > VM? > > I was pointed to former JvmtiClassFileReconstitutor ... something like that? > JvmtiClassFileReconstitutor exists precisely to recreate the full class > bytecode from the metadata when needed. I believe it is only ever needed > to allow a ClassFileTransformer to retransform a loaded class that was > not transformed at load time. Using it seems like overkill to me (also > see below). If you want to locate a specific bytecode instruction in a > method you should be able to do so by pulling the method bytecodes out > of the metadata. > > Also, if you want your message to reflect the bytecode that is actually > in use when the exception occurs then you really need to do it by > pulling the bytecodes out of the method metadata. The bytecode returned > by JvmtiClassFileReconstitutor will not include any bytecode changes > that were installed by a ClassFileTransformer. > > However, this is a potential can of worms because old and new versions > of a method and associated bytecode can exist at the same time. You need > to be sure which version of the method and, hence, bytecode the > exception was generated from. If you are trying to do this from Java by > calling into the JVM then I think you are going to have problems. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
