JDK-7147987 : Performance regression in ByteBuffer.{put,get}
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7,8,9,10
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2012-02-22
  • Updated: 2020-11-03
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-7147227 - Performance Regression in ByteBuffers
Relates :  
JDK-6878481 - Add performance counters in the JDK
Description
This is JDK part of JDK-7147227 bug which I want to keep to track VM performance regression.
Comments
Have to check generated code by Graal for this case.
08-03-2018
9-defer-SQE-ok: agreed on defer request reason
17-06-2016
9-defer-request: Long-standing (since 2012) performance-related problem.
15-06-2016
Justification for the "Medium" impact from above. This is a performance regression, therefore the impact is normally "High". However, the issue has been present since 2012 and customers have been experiencing it for a long time. As there was no input coming from customers showing major annoyance, I reduced the impact from "High" to "Medium".
30-05-2016
ILW=MMH=P3 Deferring to JDK 10 as the compiler team does not have the resources to investigate this issue at this time.
25-05-2016
ILW=Performance regression, fairly common use case, none=HMH=P2
25-09-2014
Please evaluate if this is still an issue.
30-04-2014
EVALUATION With 6u29 then the only subtype of ByteBuffer that is loaded by this test is HeapByteBuffer. With JDK7 then MappedByteBuffer is additionally loaded because it is used for mapping the instrumentation buffer in support of new performance counters in the class loading code. The additional substype means C2 cannot do some optimizations and this explains the slow down between jdk7-b69 and jdk7-b73. It's not clear that we can do anything this as the majority of applications loading DirectByteBuffer (a subtype of MappedByteBuffer) when doing I/O or other operations.
23-02-2012