-
Enhancement
-
Resolution: Fixed
-
P4
-
17
-
b24
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8269683 | 11.0.13-oracle | Harold Seigel | P4 | Resolved | Fixed | b01 |
JDK-8269880 | 11.0.13 | Aleksey Shipilev | P4 | Resolved | Fixed | b01 |
The motivation is timeouts like JDK-8267348. Note that we are spending a significant amount of time getting pc = os::current_frame() during oop registration.
As far as I understand from the Hotspot code, that is only to print the PC when the unhandled oops detector fails _itself_:
// If an entry is on the unhandled oop list but isn't on the stack
// anymore, it must not have gotten unregistered properly and it's a bug
// in the unhandled oop generator.
Since that condition must be rare, we can save considerable time not taking "pc" on every oop registration, with a minor (?) downside that we would not get the PC when unhandled oops detector is broken.
Motivational example is the test that enters the registrator path very often:
$ time CONF=linux-x86_64-server-fastdebug make run-test TEST=gc/epsilon/TestClasses.java TEST_VM_OPTS="-XX:+CheckUnhandledOops"
Before:
real 6m7.516s
user 6m38.876s
sys 0m4.566s
After:
real 2m33.344s
user 3m4.788s
sys 0m4.351s
Tier1 also improves significantly:
$ time CONF=linux-x86_64-server-fastdebug make run-test TEST=tier1 TEST_VM_OPTS="-XX:+CheckUnhandledOops"
Before:
real 60m43.022s
user 1546m54.452s
sys 45m0.769s
After:
real 42m59.204s
user 1347m41.339s
sys 50m43.837s
For the reference, the baseline without CheckUnhandledOops enabled:
$ time CONF=linux-x86_64-server-fastdebug make run-test TEST=tier1
real 32m57.509s
user 1230m5.149s
sys 54m23.135s
In other words, this cuts out about 2/3 of CheckUnhandledOops overhead.
As far as I understand from the Hotspot code, that is only to print the PC when the unhandled oops detector fails _itself_:
// If an entry is on the unhandled oop list but isn't on the stack
// anymore, it must not have gotten unregistered properly and it's a bug
// in the unhandled oop generator.
Since that condition must be rare, we can save considerable time not taking "pc" on every oop registration, with a minor (?) downside that we would not get the PC when unhandled oops detector is broken.
Motivational example is the test that enters the registrator path very often:
$ time CONF=linux-x86_64-server-fastdebug make run-test TEST=gc/epsilon/TestClasses.java TEST_VM_OPTS="-XX:+CheckUnhandledOops"
Before:
real 6m7.516s
user 6m38.876s
sys 0m4.566s
After:
real 2m33.344s
user 3m4.788s
sys 0m4.351s
Tier1 also improves significantly:
$ time CONF=linux-x86_64-server-fastdebug make run-test TEST=tier1 TEST_VM_OPTS="-XX:+CheckUnhandledOops"
Before:
real 60m43.022s
user 1546m54.452s
sys 45m0.769s
After:
real 42m59.204s
user 1347m41.339s
sys 50m43.837s
For the reference, the baseline without CheckUnhandledOops enabled:
$ time CONF=linux-x86_64-server-fastdebug make run-test TEST=tier1
real 32m57.509s
user 1230m5.149s
sys 54m23.135s
In other words, this cuts out about 2/3 of CheckUnhandledOops overhead.
- backported by
-
JDK-8269683 Avoid recording "pc" in unhandled oops detector for better performance
- Resolved
-
JDK-8269880 Avoid recording "pc" in unhandled oops detector for better performance
- Resolved
- relates to
-
JDK-8267348 Rewrite gc/epsilon/TestClasses.java to use Metaspace with less classes
- Resolved
- links to
-
Commit openjdk/jdk11u-dev/d424c0ce
-
Commit openjdk/jdk/f67847f5
-
Review openjdk/jdk11u-dev/71
-
Review openjdk/jdk/4114
(2 links to)