RFR (XS): 8141677: Improve java.lang.invoke.MemberName hashCode implementation

[Claes Redestad]

Vladimir,

I instrumented and counted 7 invocations of MethodName.hashCode during 
initialization, so I agree the only real concern from a startup point of 
view is avoiding Byte$ByteCache:

http://cr.openjdk.java.net/~redestad/8141677/webrev.02/

Thanks!

/Claes

On 2015-11-09 12:33, Vladimir Ivanov wrote:
> Claes,
>
> If you want to avoid Byte$ByteCache initialization, don't you achieve 
> the same just by wrapping reference kind manually [1]?
>
> Regarding getting rid of varags method call (Objects.hashCode), do you 
> see any measurable improvements? I'm reluctant to see such changes 
> (manual method body inlining) unless the affected code is really hot.
>
> Best regards,
> Vladimir Ivanov
>
> [1] diff --git 
> a/src/java.base/share/classes/java/lang/invoke/MemberName.java 
> b/src/java.base/share/classes/java/lang/invoke/MemberName.java
> --- a/src/java.base/share/classes/java/lang/invoke/MemberName.java
> +++ b/src/java.base/share/classes/java/lang/invoke/MemberName.java
> @@ -694,7 +694,7 @@
>
>      @Override
>      public int hashCode() {
> -        return Objects.hash(clazz, getReferenceKind(), name, getType());
> +        return Objects.hash(clazz, new Byte(getReferenceKind()), 
> name, getType());
>      }
>      @Override
>      public boolean equals(Object that) {
>
> On 11/8/15 3:30 PM, Claes Redestad wrote:
>> Hi,
>>
>> MemberName::hashCode is exercised during startup of jake, and is
>> currently implemented using Objects.hash(...), which allocates Object[]s
>> and boxes bytes.
>>
>> Inlining this makes this slightly more efficient before the JIT kicks
>> in, but more measurably allows initialization of Byte$ByteCache to be
>> deferred from startup:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8141677
>> webrev: http://cr.openjdk.java.net/~redestad/8141677/webrev.01/
>>
>> /Claes