RFR (S) 8140685: Fix backtrace building to not rely on constant pool merging

[Coleen Phillimore]

Kim, thank you for reviewing, and past almost endless discussions of 
this problem.

On 1/23/17 9:35 PM, Kim Barrett wrote:
>> On Jan 23, 2017, at 6:00 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>
>> Summary: Store Symbol* for the name in the backtrace
>>
>> There was some thought that storing a u2 for cpref would be more memory efficient than storing Symbol* in the backtraces, but recent runs of Jetty show that this doesn't cause footprint increases or performance decreases.   Storing the Symbol* for the method name guarantees it is there when creating the StackTraceElement, whereas cpref relies on constant pool merging for redefinition and is dependent on being an index in the right constant pool, which has been a source of bugs in the past.
>>
>> dev-submit performance testing was run with no regressions.  Also, all hotspot jtreg tests were run.
>>
>> This is a change for JDK10 whenever that opens.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>>
>> Thanks,
>> Coleen
> Looks good.  Just a couple of minor nits.
>
> ------------------------------------------------------------------------------
> src/share/vm/classfile/javaClasses.cpp
> 1631     assert(_methods->length() == _bcis->length() &&
> 1632            _methods->length() == _mirrors->length(),
>
> Pre-existing: Shouldn't the _names (formerly _cprefs) length also be
> checked here?

     assert(_methods->length() == _bcis->length() &&
            _methods->length() == _mirrors->length() &&
            _mirrors->length() == _names->length(),
            "method and source information arrays should match");

Yes.
>
> ------------------------------------------------------------------------------
> src/share/vm/classfile/javaClasses.cpp
> 1694     // Note:this doesn't leaks symbols because the mirror in the backtrace keeps the
>
> s/leaks/leak

I corrected this also.

Thanks!
Coleen
> ------------------------------------------------------------------------------
>