RFR (XS): 8141677: Improve java.lang.invoke.MemberName hashCode implementation
Claes Redestad
claes.redestad at oracle.com
Mon Nov 9 14:26:10 UTC 2015
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
More information about the core-libs-dev
mailing list