JDK-8297835 : aarch64: Subclasses of Address get sliced
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 20
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • CPU: aarch64
  • Submitted: 2022-11-30
  • Updated: 2022-12-01
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 :  
Description
The aarch64 Address class has a number of subclasses for various kinds of literal addresses: RuntimeAddress, ExternalAddress, OopAddress, InternalAddress.

OopAddress appears to be unused, so can be deleted.

The others are all subject to slicing, since the Address dtor/copy/assign are all public.  And indeed they get sliced, since (almost) all uses of these subclasses are just to construct an argument to be passed by value to a function taking an Address object. So a slicing copy, with the derived type being of no real importance. While it works, it's icky and unnecessary.

A better approach (that avoids copy-slicing) would be to replace those subclasses with static functions with the names of those subclasses, with each function returning an appropriately initialized Address object.

There are a couple places where one of these derived types is used as a local variable's type.  Those can be changed to Address without any loss of functionality or readability.