JDK-8269838 : BasicTypeDataBase.findDynamicTypeForAddress(addr, basetype) can be simplified
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 18
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-07-02
  • Updated: 2022-01-03
  • Resolved: 2021-12-15
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 19
19 b03Fixed
Related Reports
Relates :  
JDK-8251852 - 3 SA tests fail with "does not appear to be polymorphic" error
Relates :  
JDK-8269830 - SA's vm object vtable matching code sometimes matches on incorrect type
Description
This is very much related to JDK-8269830 and how BasicTypeDataBase.addressTypeIsEqualToType(addr, type) looks at the end of the object to find vtableptrs, which is only necessary on Solaris, which is no longer supported. This could lead to matching on the wrong type, although unlike JDK-8269830 I don't know of any test failures as a result of this, so the fix is not being included with JDK-8269830.

All the loc2 and loc3 related code in BasicTypeDataBase.findDynamicTypeForAddress(addr, basetype) should be stripped out. This would make it much simpler, and get rid of the risk of matching on the wrong type.
Comments
Changeset: 7517c85d Author: Chris Plummer <cjplummer@openjdk.org> Date: 2021-12-15 17:08:44 +0000 URL: https://git.openjdk.java.net/jdk/commit/7517c85da3236e5274580645d4c3cdecb1db25c5
15-12-2021