-
Bug
-
Resolution: Fixed
-
P4
-
8, 11, 15
-
b24
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8247921 | 13.0.5 | Thomas Stuefe | P4 | Resolved | Fixed | b01 |
JDK-8252561 | 11.0.10-oracle | Thomas Stuefe | P4 | Resolved | Fixed | b01 |
JDK-8245084 | 11.0.8 | Thomas Stuefe | P4 | Resolved | Fixed | b04 |
JDK-8245698 | openjdk8u262 | Thomas Stuefe | P4 | Resolved | Fixed | b04 |
ClassLoaderStats VM Operation can take a long time when a lot of class loaders are involved.
See: https://mail.openjdk.java.net/pipermail/hotspot-jfr-dev/2020-May/001430.html
It iterates the CLDG and accumulates statistics per class loader over all CLDs. It uses a temporary ResourceHashTable for that.
The hash function is wrong though.
static unsigned oop_hash(oop const& s1) {
unsigned hash = (unsigned)((uintptr_t)&s1);
return hash ^ (hash >> LogMinObjAlignment);
}
There are two errors which independently from each other cause the hash to be constant:
- we use &s1, so we calculate the hash based on the address of the key carrier not the key
- we use LogMinObjAlignment instead of LogMinObjAlignmentInBytes, which is usually 0, so we xor out the hash at the end.
- backported by
-
JDK-8245084 ClassLoaderStats VM Op uses constant hash value
-
- Resolved
-
-
JDK-8245698 ClassLoaderStats VM Op uses constant hash value
-
- Resolved
-
-
JDK-8247921 ClassLoaderStats VM Op uses constant hash value
-
- Resolved
-
-
JDK-8252561 ClassLoaderStats VM Op uses constant hash value
-
- Resolved
-