Reviewed. Best regards, Vladimir Ivanov
On 11/9/15 5:26 PM, Claes Redestad wrote:
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
