RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

[Andrew Dinn]

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