This issue has been filed to address the determination of TNSFF for "record classes" in the Hotspot VM.

Details below are copied from a comment in JDK-8255560 - which addresses the Core Reflection aspects of the issue.

---
RE: ���The Record Attribute - What does it mean to be a record at runtime��� 

In order to claim a non-static final field is trusted, such TNSFF must not be modifiable by reflection and method handle (VarHandle does not allow writing on a final field). Unsafe is a lessen concern because it���s unsafe anyway but we should stop what we can. We want records to benefit from TNSFF performance but not care so much normal classes with RecordComponents attribute. JIT optimization is implementation-specific. Checking if a class is a subclass of java.lang.Record should not be expensive. I would suggest to change JIT to check if a class must be final and a subclass of java.lang.Record in addition to the presence of a RecordComponents attribute. 

In HotSpot implementation term, the current implementation of InstanceKlass::is_record is misleading because it could return true on a normal class. The suggested fix is to change InstanceKlass::is_record to check if _record_components != NULL and it is final and a subclass of java.lang.Record. No change in JVM class file validation. 

[1] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-November/002630.html