RFR 8071627: Code refactoring to override == operator of Symbol*

[Lois Foltan]

Hi Calvin,

I haven't fully reviewed all of your changes yet but since I suspect 
this review to go through more than one iteration, here are some of my 
initial concerns.

  - passing by value vs. passing by reference
    passing the new SymbolRef class by value potentially causes the C++ 
compiler to copy construct the value.  Can parameters of type SymbolRef 
be changed "const SymbolRef&" to avoid the copy construct?

  - I find myself somewhat surprised that no performance degradation did 
occur.  For example an often used statement like the following:
    SymbolRef variable = NULL;
                    vs.
    Symbol* variable = NULL;

    Now involves a call to construct NULL into a SymbolRef and then a 
copy construct to assign the resulting SymbolRef into variable.

I will continue to review and send along further comments shortly.

Thanks,
Lois

On 4/2/2015 8:48 PM, Calvin Cheung wrote:
> Please review this enhancement for Symbol comparison.
> This should allow future enhancement such as multiple SymbolTable and 
> symbols with the same utf8 strings in different tables should be 
> considered "equivalent".
>
> Although this changeset touches many files, the main change is in 
> src/share/vm/oops/symbol.hpp with a new SymbolRef class. The rest of 
> the change is mostly replacing Symbol* with SymbolRef.
>
> Since currently there's only one single SymbolTable, it isn't feasible 
> to write a specific testcase for this enhancement. We will provide a 
> testcase when this enhancement is used.
>
> Note also that the copyright header will be fixed before this 
> changeset is committed.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8071627
>
> webrev: http://cr.openjdk.java.net/~ccheung/8071627/webrev.00/
>
> Tests:
>     JPRT
>     nsk.jvmti on linux_x64
>
>     the following performance benmarks on linux_x64, solaris_x64, 
> solaris_sparc, mac, windows_x64 with no significant performance 
> degradation:
>         jetstream, scimark, specjbb2000, specjbb2005, specjvm98, volano25
>
>     some internal class loading performance tests
>
> thanks,
> Calvin