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

[Lindenmaier, Goetz]

Hi Coleen, 

thanks for looking at my change..

> For the record, I think the C++ implementation is more straightforward
> than trying to use the Stackwalker and ASM because there's other code
> just like it right here. You have all the information you need directly
> in the Throwable.backtrace field. Walking it makes sense to me.  Also
> the StackWalker has a cost because it creates ResolvedMethodNames that
> must be interned in the native code in case of redefinition.
Yes, I also think that a Java implementation has more costs at 
runtime.  But as this is only encountered if the message is actually
accessed, it's not that much of a concern.

> I didn't make it through the code for bytecodeUtils but I think it
> should be in the interpreter directory where all the other bytecode
> iterating methods are.  
I moved it to the interpreter directory.
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/05-otherMessages/

> It does seem expensive when printing an NPE
> message.  I wonder if there's some easily helpful variable names that
> you could pick out and not have to do all this work for every sort of
> bytecode. 
I'll describe the algorithm in some detail in the paper requested. 
This might answer this point. 

> Also the file uses non hotspot names also like
> 'createInvalidSource' that should be fixed.
I still need to fix these. I’ll leave this to a final review.  The 
code still might be discarded in favour of another implementation.

> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-
> NPE/02/src/hotspot/share/classfile/javaClasses.cpp.udiff.html
> 
> There's a 'version' in the backtrace.  If the method->version() doesn't
> match the one in the backtrace, this should return false, because the
> method was redefined and the bci probably won't match. There's a bunch
> of code in javaClasses that does the similar thing.
Starting with the back trace, I will always get the right bytecodes.
The backtrace keeps the method alive as I understand.

The problem I mentioned in other mails is to get that accessible in Java code ... 
for the C-implementation I have all the proper information 
just per design of the metaspace/backtrace etc. at hand.

Best regards,
  Goetz.



> 
> This isn't a full review.
> 
> Thanks,
> Coleen
> 
> >
> > Thanks!
> >    Goetz
> >
> >> Also, it was not strictly correct when I said all that is retained is
> >> the method bytecodes. Exception tables, line number tables and local var
> >> name & type tables are also retained.
> >>
> >> 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