JDK-8293118 : AccessFlags should be just the classfile flags
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 20
  • Priority: P4
  • Status: Closed
  • Resolution: Delivered
  • Submitted: 2022-08-30
  • Updated: 2024-09-03
  • Resolved: 2023-05-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
tbdResolved
Related Reports
Relates :  
JDK-8298475 - Remove JVM_ACC_PROMOTED_FLAGS
Relates :  
JDK-8307533 - Use atomic bitset functions for metadata flags
Relates :  
JDK-8339112 - Move JVM Klass flags out of AccessFlags
Relates :  
JDK-8292818 - replace 96-bit representation for field metadata with variable-sized streams
Relates :  
JDK-8293117 - Add atomic bitset functions
Relates :  
JDK-8339113 - AccessFlags can be u2 in metadata
Sub Tasks
JDK-8295964 :  
Move InstanceKlass::_misc_flags - Resolved
JDK-8300682 :  
InstanceKlassMiscStatus is a bad name - Resolved
JDK-8306123 :  
Move InstanceKlass writeable flags - Resolved
JDK-8306310 :  
Move is_shared Klass flag - Resolved
JDK-8306474 :  
Move InstanceKlass read-only flags - Resolved
JDK-8306482 :  
Remove unused Method AccessFlags - Resolved
JDK-8306851 :  
Move Method access flags - Resolved
JDK-8307295 :  
Add warning to not create new ACC flags - Resolved
Description
The accessFlags in field, method and klass should be only the ones that javac puts in the classfile.  JVM state should be separated out to other flag or status bits, depending on whether they are read-only or, in the case of status flags, read-write.   The read-write flags should be written atomically.

Adding flags to accessFlags for valhalla and other new projects in Amber, have exposed the need to fix this area of technical debt.
Comments
We are stuck with the old decision to extend some AF fields (but not all) to 32 bits. I would like to drive towards a future in which (a) all AF instances are 16 bits, and (b) all of the assembly code which currently sneaks extra bits from the 32-bit field (in IK) is recoded to pull those bits from somewhere else. ("Somewhere else" being, some field not named or typed as “access flags".) I would also like to avoid a future where folks notice there are 12 unused bits in the top of the 32-bit AF field (IK) and start using them; that feels like regression (increase of tech debt), and likewise with fields and methods. Avoiding the second future means putting a warning in a conspicuous place. (One might consider this comment as such a warning.) Achieving the first future is difficult, since either all assembly code changes in one Big Bang, or else there is a phased migration of the Special Four bits Coleen found, a migration where (during a transition period) the bits are in either (or both) of two places, and the assembly code of each platform either is updated to access them in the New Place, or the assembly code is allowed to bone-headedly believe that the bits are still in the Old Place. Making things comfy for the old code means that the Old Place needs to be 32 bits, and that means arranging the byte-order of those 32 bits differently on platforms with different byte order. Yuck. As I write this I’m thinking we should deprecate and eventually retire `Klass::_access_flags`, an its associated assembly offset, completely. This is not a process I wish to launch now, but I do wish to state that this is technical debt we may be called to pay off at some point. (addition, following an observation by Coleen) To reduce assembly code churn, the Old Place (`Klass::_access_flags`) can always store the 16 access flags bits, and be accessed variously as 16 or 32 bits from a assembly code, with 16-bit accesses being always valid before and after splitting the high 16 out to the New Place. The Old Place shrinks down to 16 bits with no assembly changes for code which already uses 16-bit access. This works because the current 32-bit slot can be addressed by as a 16-bit slot with no code changes on little-endian machines, and with small code changes on a big-endian machine. To keep track across multiple platforms changing at different times, the `access_flags_offset()` accessor should be renamed in some way to reflect the kind of the access. Perhaps, as a minimum, `Klass::_access_flags` should be accessed (at least on big endian machines) by assembly code which refers to a new accessor `u2_access_flags_offset()`; such assembly code will not need changes when the slot shrinks from 32 to 16 bits.
03-05-2023
We could migrate one by one (steps 1-4) but that would have to be assigned to a compiler person. When that's done (step 5), change AccessFlags::_flags to a u2 and make sure the load/tests are the right size for is_native() and other places where we test the access flags in compiled and interpreted code, look for Klass::access_flags_offset() and Method::access_flags_offset().
02-05-2023
There are 4 access flags are used by generated code in the compilers and interpreters. // Klass* flags JVM_ACC_HAS_FINALIZER = 0x40000000, // True if klass has a non-empty finalize() method JVM_ACC_IS_CLONEABLE_FAST = (int)0x80000000,// True if klass implements the Cloneable interface and can be optimized in generated code JVM_ACC_IS_HIDDEN_CLASS = 0x04000000, // True if klass is hidden JVM_ACC_IS_VALUE_BASED_CLASS = 0x08000000, // True if klass is marked as a ValueBased class The generated code tests these flags with 32 bit loads and tests of access_flags_offset(), so moving these to a u2 _klass_flags field with klass_flas_offsets() and making AccessFlags u2 rather than u4, would create a lot of churn in all of the platform ports. There doesn't seem to be a good reason to do this. So these flag will remain in AccessFlags unless otherwise needed to be moved. The new metadata flags fields added for InstanceKlass, Method and ConstMethod can be extended simply for new fields which was the reason to do this.
01-05-2023