RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.
goetz.lindenmaier at sap.com
Thu Feb 21 12:57:00 UTC 2019
thanks for giving this advice! It confirms the problems I see.
For the context:
I proposed better NPE exception messages:
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...
> -----Original Message-----
> From: Andrew Dinn <adinn at redhat.com>
> Sent: Mittwoch, 20. Februar 2019 18:29
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; hotspot-runtime-
> dev at 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
> > 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.
> 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
More information about the core-libs-dev