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

John Rose john.r.rose at oracle.com
Mon Aug 5 22:19:59 UTC 2019

On Aug 5, 2019, at 8:10 AM, Frederic Parain <frederic.parain at oracle.com> wrote:
> 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
> information.
> 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.

There’s a database-flavored way to do this also:

Issue one event for the layout as a whole, and associate it with an ID number N.

Then, for each field (or hole?) in the layout, issue another separate event, mentioning the original ID number N.

(The database angle is that a client can form up the variable-sized answer by joining on N.)

Perhaps JFR events already have an intrinsic ID number, in which case the pattern gets simpler.

In general it would be nice if there were a way to cluster JFR events, even into large multi-level clusters like today’s LogCompilation task reports.

More information about the valhalla-dev mailing list