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