-
Bug
-
Resolution: Fixed
-
P4
-
21, 22
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8318881 | 21.0.2 | Hannes Greule | P4 | Resolved | Fixed | b05 |
This causes a performance regression in jcmd GC.heap_dump, which uses FieldStream from reflectionUtils.hpp. This implementation has two flaws in combination with the change from
1. It uses field indexes to access data, e.g. _klass->field_access_flags(_index) to get a field's access flags.
2. It traverses the fields in reverse order. The way how the metadata is stored now only allows for efficient forward traversal.
As an example, running the attached Java file and creating a heap dump takes (on my machine):
- 2-3 seconds on Java 17
- ~20 seconds on Java 21
FieldStream cannot directly be replaced by the implementations from fieldStreams.hpp because it additionally traverses supertypes.
The proposed fix is to add field streaming with supertype traversal to fieldStreams.hpp. This way, other usages of FIeldStream are unaffected in behavior. The new implementation does foward traversal over the fields but keeps the order in which supertypes visited from FieldStream. This way, the produced heap dump will still conform to the hprof format.
Relevant mailing list discussion: https://mail.openjdk.org/pipermail/serviceability-dev/2023-October/051571.html
- backported by
-
JDK-8318881 jcmd GC.heap_dump performance regression after JDK-8292818
- Resolved
- blocks
-
JDK-8318563 GetClassFields should not use random access to field
- Resolved
- relates to
-
JDK-8292818 replace 96-bit representation for field metadata with variable-sized streams
- Resolved
-
JDK-8318563 GetClassFields should not use random access to field
- Resolved
- links to
-
Commit openjdk/jdk21u/c5a6a74a
-
Commit openjdk/jdk/8f5f4407
-
Review openjdk/jdk21u/274
-
Review openjdk/jdk/16083