RFR(XL): JDK-8228441 Field layout requires complete overhaul to efficiently support inline classes

Frederic Parain frederic.parain at oracle.com
Mon Aug 5 15:10:05 UTC 2019


I’ve investigated the creation of JFR events to report field layout decisions,
but there’s a big problem. Layouts have variable sizes (number of fields being
controlled class definitions), and there’s no support in the JVM for JFR events
with a variable size.

I’ve discussed the issue with Markus. There’s a way to declare and fire JFR events
with variable sizes with Java code, but no such feature is planned for the JVM
(and even if it is, it will probably a JNI wrapper around the Java code doing it).
The problem is that layouts are computed very early in the JVM startup (the first
class to be loaded, java/lang/String, has fields!), and at this stage, there isn’t
enough classes initialized to execute JFR code. 

Another solution would be to have a fixed size JFR event, and to encode all the
layout information in a single string. But 1) it won’t be easily readable by humans,
and 2) it would require specific supports in tools to parse and represent layout

I’m investigating if putting the layout information in the general logging framework
would make sense. But once again, the nicest way to represent a layout requires
multiple consecutive lines of text, and I have to figure out how it is possible
to have this format guaranteed.



> On Jul 19, 2019, at 11:32, Brian Goetz <brian.goetz at oracle.com> wrote:
> Great to see support for making it easier to inspect what decisions the VM is actually making here.  Rather than a DCMD, did you consider using JFR events to log these decisions, now that JFR is universally available?
>> On Jul 19, 2019, at 11:26 AM, Frederic Parain <frederic.parain at oracle.com> wrote:
>> This changeset also includes some options and DCMD to ease inspection
>> of layouts, especially when flattenable fields are involved.

More information about the valhalla-dev mailing list