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

Frederic Parain frederic.parain at oracle.com
Wed Aug 7 20:18:28 UTC 2019



> On Aug 5, 2019, at 18:19, John Rose <john.r.rose at oracle.com> wrote:
> 
> 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.
> 

Thank you for this suggestion. This is something that could be implemented
easily in the JVM. However, I’m concerned about the usability on the user
side. Without a proper support on the client side, users are likely to be
overwhelmed by thousands or tens of thousands of events, and it would be
a real challenge to reconstruct the layout of each class.

I’ll discuss with Markus if there’s some ways to help reconstruct the
information on the client side.

Fred




More information about the valhalla-dev mailing list