JDK-8169698 : SA: Check and fix cases of potential data loss due to 'long' to 'int' truncation with calls to minus()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 8u112,9
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2016-11-15
  • Updated: 2021-07-30
  • Resolved: 2021-07-30
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
tbdResolved
Related Reports
Relates :  
Description
The minus() methods in the platform specific address classes return values of type 'long'. But there are multiple areas where these return values are read into values of type 'int', with deliberate casts, thus causing potential loss of data. 

An example: 
share/classes/sun/jvm/hotspot/asm/Disassembler.java

48    public static void decode(InstructionVisitor visitor, CodeBlob blob, Address begin    , Address end) {
49       int codeSize = (int)end.minus(begin);

Comments
This seems like a non-issue. Uses are always of the above form given in the example. Basically trying to find the size of some object or block of memory. I don't believe these would ever overflow an int. The above example is typical. It's a CodeBlob.It's will be smaller than 2gb. The only exception I can think of is possibly something GC related. For example, calculating the size of all reserved memory in this fashion. But certainly heap sizes greater than 2g are already common, and if there was an issue we would have seen it already. And if the concern is gc regions being larger than 2gb, this calculation is already done properly: // Summarize size long totalSize = 0; for (int i = 0; i < liveRegions.size(); i += 2) { Address bottom = (Address) liveRegions.get(i); Address top = (Address) liveRegions.get(i+1); totalSize += top.minus(bottom); } There is also this example of correct code for memory region sizes: public long committedSize() { return high().minus(low()); } public long reservedSize() { return highBoundary().minus(lowBoundary()); } public long uncommittedSize() { return reservedSize() - committedSize(); } Note that JDK-8169232 was a real bug, but it was the result of down casting a long to an int in an inappropriate way. I think this CR is in search of a bug that doesn't exist. Closing as "No an Issue".
30-07-2021