JDK-8230036 : ciReceiverTypeData::translate_receiver_data_from overkilled some type profile data
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 14
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86_64,aarch64
  • Submitted: 2019-08-22
  • Updated: 2019-08-22
  • Resolved: 2019-08-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 14
14Resolved
Related Reports
Duplicate :  
Relates :  
Description
A couple of benchmarks got obvious performance loss about 5~6% with changeset 55956, the problem was initially reproduced at Ampere eMAG aarch64 system, later on the similar loss can be seen on a x86 system as well.

https://bugs.openjdk.java.net/browse/JDK-8225670
https://hg.openjdk.java.net/jdk/jdk/rev/155b084cf384

On the aarch64 system, a few GC logs showed "Promotion failed" and 1-2 ~50s long pauses, which is very abnormal. A simple and straight-forward change is made as an experiment below, limiting the clear_row(row) with the (k!=NULL) condition, so the profiled data without a valid receiver stored in the original ReceiverTypeData would not be destroyed accidentally. In this way, the performance can be recovered (please note this is not a fix).

src/hotspot/share/ci/ciMethodData.cpp
if (k != NULL && k->is_loader_alive()) {
  ciKlass* klass = CURRENT_ENV->get_klass(k);
  set_receiver(row, klass);
} else {
// With concurrent class unloading, the MDO could have stale metadata; override it
+ if (k != NULL) 
  clear_row(row);

Another experiment is, setting -XX:TypeProfileWidth=0 could help confirm the issue can be related with this function, since the performance diffs are gone if we did so.

Comments
caused by the fix of JDK-8225670
22-08-2019