RFR: 8332249: Micro-optimize Method.hashCode [v2]
Aleksey Shipilev
shade at openjdk.org
Thu Jul 11 10:07:02 UTC 2024
On Tue, 11 Jun 2024 08:58:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> Sean Gwizdak has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>>
>> - Remove trailing whitespace.
>> - Move hashCode benchmark into the newly created MethodBenchmark file
>> - Merge branch 'master' into method-hashcode-JDK-8332249
>> - Remove changes to JavaDoc per guidance.
>> - Fix whitespace issues pointed by the bot
>> - Micro-optimize Method.hashCode
>
> As usual in these cases, we need to make a footprint argument as well. `Method` is a special class with lots of injected fields, so the only "true" source of layout information is `-XX:+PrintFieldLayout`. It tells me there is a 4-byte tail due to object alignment in compressed oops mode. This can accommodate a new `int` field. There seems to be no space when compressed oops are disabled.
>
>
> # Out of the box, compressed oops enabled
> Layout of class java/lang/reflect/Method
> Instance fields:
> @0 12/- RESERVED
> @12 "override" Z 1/1 INHERITED
> @13 "callerSensitive" B 1/1 REGULAR
> @14 2/1 EMPTY
> @16 "accessCheckCache" Ljava/lang/Object; 4/4 INHERITED
> @20 "parameterData" Ljava/lang/reflect/Executable$ParameterData; 4/4 INHERITED
> @24 "declaredAnnotations" Ljava/util/Map; 4/4 INHERITED
> @28 "slot" I 4/4 REGULAR
> @32 "modifiers" I 4/4 REGULAR
> @36 "clazz" Ljava/lang/Class; 4/4 REGULAR
> @40 "name" Ljava/lang/String; 4/4 REGULAR
> @44 "returnType" Ljava/lang/Class; 4/4 REGULAR
> @48 "parameterTypes" [Ljava/lang/Class; 4/4 REGULAR
> @52 "exceptionTypes" [Ljava/lang/Class; 4/4 REGULAR
> @56 "signature" Ljava/lang/String; 4/4 REGULAR
> @60 "genericInfo" Lsun/reflect/generics/repository/MethodRepository; 4/4 REGULAR
> @64 "annotations" [B 4/4 REGULAR
> @68 "parameterAnnotations" [B 4/4 REGULAR
> @72 "annotationDefault" [B 4/4 REGULAR
> @76 "methodAccessor" Ljdk/internal/reflect/MethodAccessor; 4/4 REGULAR
> @80 "root" Ljava/lang/reflect/Method; 4/4 REGULAR
> Instance size = 88 bytes
>
> # -XX:-UseCompressedOops
> Layout of class java/lang/reflect/Method
> Instance fields:
> @0 12/- RESERVED
> @12 "override" Z 1/1 INHERITED
> @13 "callerSensitive" B 1/1 REGULAR
> @14 2/1 EMPTY
> @16 "accessCheckCache" Ljava/lang/Object; 8/8 INHERITED
> @24 "parameterData" Ljava/lang/reflect/Executable$ParameterData; 8/8 INHERITED
> @32 "declaredAnnotations" Ljava/util/Map; 8/8 INHERITED
> @40 "slot" I 4/4 REGULAR
> @44 "modifiers" I 4/4 REGULAR
> @48 "clazz" Ljava/lang/Class; 8/8 REGULAR
> @56 "name" Ljava/lang/String; 8/8 REGULAR
> @64 "returnType" Ljava/lang/Class; 8/8 REGULAR
> @72 "parameterTypes" [Ljava/lang/Class; 8/8 REGULAR
> @80 "exceptionTypes" [Ljava/lang/Class; 8/8 REGULAR
> @88 "signature" Ljava/lang/String; 8/8 REGULAR
> @96 "genericInfo" Lsun/reflect/generics/repository/MethodRepository; 8/8 REGULAR
> @104 "annotations" [B 8/8 REGULAR
> @112 "parameterAnnotations" [B 8/8 REGULAR
> @120 "annotationDefault" [B 8/8 REGULAR
> @128 "methodAccessor" Ljdk/internal/reflect/MethodAccessor; 8/8 REGULAR
> @136 "root" Ljava/...
> @shipilev Any recommendations on reducing footprint size?
I see two ways from here:
1. There seems to be a 2-byte gap in the object, so if we can squeeze out 2 additional bytes, it would allow us to put another `int` in. It looks like `slot` does not have to be `int`: on VM side, it is `u2` (unsigned 2-byte), which might be just `short` or `char` with proper precautions about signs and conversions. That would probably be a bit ugly.
2. Ignore this regression and move on. It would have been a non-issue if `Method`-s were canonicalized/de-duplicated in some way. But AFAICS, `Method`-s are getting copied from `Class.getDeclaredMethods`, so it is probable we have quite a few instances floating around, and footprint regressions would stack up.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19433#issuecomment-2222532168
More information about the core-libs-dev
mailing list