-
Bug
-
Resolution: Fixed
-
P3
-
8u112
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8348228 | 8-pool | David Holmes | P3 | New | Unresolved | |
JDK-8257276 | emb-8u281 | Fairoz Matte | P3 | Resolved | Fixed | team |
NOTE: This was fixed in Oracle JDK 8u281 only.
Starting from JDK 8u112 certain JVMTI functions became extremely slow. All these functions accept jmethodID as an argument.
- GetMethodName
- GetMethodDeclaringClass
- GetMethodModifiers
- GetLineNumberTable
- GetBytecodes
etc.
The attached code demonstrates the problem. This code executes GetMethodDeclaringClass one million times. It works 86 ms on JDK 8u102, but it takes 360'000 ms on JDK 8u141.
The problem appeared afterJDK-8147451. The fix introduced a validity check Method::is_method_id for each translation of jmethodID argument. This involves a linear search among all jmethodIDs. Various tools like profilers allocate jmethodIDs for many loaded classes, so that the total number of jmethodIDs may reach hundreds of thousands. Linear search is not going to work in such cases.
Starting from JDK 8u112 certain JVMTI functions became extremely slow. All these functions accept jmethodID as an argument.
- GetMethodName
- GetMethodDeclaringClass
- GetMethodModifiers
- GetLineNumberTable
- GetBytecodes
etc.
The attached code demonstrates the problem. This code executes GetMethodDeclaringClass one million times. It works 86 ms on JDK 8u102, but it takes 360'000 ms on JDK 8u141.
The problem appeared after
- backported by
-
JDK-8257276 Major performance regression in GetMethodDeclaringClass and other JVMTI Method functions
- Resolved
-
JDK-8348228 Major performance regression in GetMethodDeclaringClass and other JVMTI Method functions
- New
- relates to
-
JDK-8147451 Crash in Method::checked_resolve_jmethod_id(_jmethodID*)
- Closed