JDK-8234627 : Potentially unexpected amount of extra data in MethodData
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 14
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2019-11-22
  • Updated: 2019-12-03
  • Resolved: 2019-12-02
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 15
15Resolved
Related Reports
Relates :  
Relates :  
Description
The changes in JDK-8233702 added a clamp() function to clamp a value between given min and max, with the assert checking whether min <= max.

Attempting to use this method in

methodData.cpp:

int MethodData::compute_extra_data_count(int data_size, int empty_bc_count, bool needs_speculative_traps) { 

933:     int extra_data_count = MIN2(empty_bc_count, MAX2(4, (empty_bc_count * 30) / 100)); 

caused the assert to fail (assuming extra_data_count should be bounded by [4...empy_bc_count]) which indicates a potential issue with the calculation, i.e. unexpected return values.

Please look at the method/calculation and if the clamp() method should be used, and if so use it after fixing the code.
Comments
Thanks, Doug.
03-12-2019

In offline discussion with [~chaeubl], it appears as though the JVMCI version of MethodData::compute_extra_data_count is from a time when Graal was not so stable. I'll open an issue to remove it.
02-12-2019

If this is the case, do you think would it be useful to change the code to use the clamp() method or probably better remove the MAX2() clause? This would help other people not ask the same question again.
02-12-2019

Okay, thanks. I don't see a reason why empty_bc_count should be >= 4, so I'm closing this as Not An Issue. If anyone disagrees, please re-open.
02-12-2019

Sorry, I have no recollection of why it is that way.
28-11-2019

The empty_bc_count argument contains the number of bytecodes that don't have any data attached. There is no reason why it should be >= 4 (especially since there can be methods with less than 4 bytecodes). This code came in with the jvmci integration (JDK-8136421). [~dnsimon] do you know why "4" is used in the expression?
28-11-2019

Okay, thanks. I think it's fine for empty_bc_count to be smaller than 4 but I'll check.
25-11-2019

Syntax is clamp(value, min, max), returning value clamped to the interval [min, max]. I think my application has been: extra_data_count = clamp(empty_by_count * 30/100, 4, empty_bc_count); Problem is that empty_bc_count is often smaller than 4, triggering the assert. Maybe current behavior is intentional for some reason, if so, just close out this issue.
22-11-2019

ILW = Potentially wrong computation of extra data in MethodData, never showed up, no workaround = MLH = P4
22-11-2019

How did you replace that expression with a clamp()?
22-11-2019