-
CSR
-
Resolution: Approved
-
P3
-
behavioral
-
low
-
New field layouts could cause trouble to tools relying on some unwritten properties of the old field layouts.
-
add/remove/modify command line option
-
Implementation
Summary
Add new VM options UseEmptySlotsInSupers
and UseNewFieldLayout
to control the new algorithm computing field layouts.
Problem
First issue
The new algorithm to compute field layouts performs more optimizations than the previous algorithm.
One of these optimizations is to allocate fields of a class in the unused slots of its super classes. This optimization provides better data density but can cause issues in two cases:
1 - allocating a field in the unused slots of a super-class breaks a property of the old algorithm which always allocated field of a class after the fields of its direct super class. This property was not written anywhere, but was exploited by some code (CI, JVMCI and deoptimization had to be modified because they were relying on this property). It is possible that tools from the Java ecosystem rely on this property too, and by consequence, could break because of the new layout,
2 - even if the JVMS doesn't provide any guarantee about the layout of fields, some users might absolutely want that fields of a given class are allocated together (for instance, to be in the same cache line). This property was naturally provided by the old algorithm but it is not the default behavior of the new algorithm.
The second optimization allows the allocation of subclass fields directly after the last field of the direct super-class, instead of aligning the first field of the subclass on a heapOopSize boundary as the old code does.
Second issue:
The old code to compute field layouts has been stable for so long that people used some of its properties as it they were behavior guaranteed by the JVM. The new code tries to be as compatible as possible with the behavior of the old code, but some of its properties could have been missed (because they are not written anywhere).
Solution
It is a bad coding practice to rely on unspecified behaviors of the JVM like the fields layout, however, to avoid breaking existing applications and tools relying on the current field layouts, the JVM should provide a way to disable aggressive optimizations during field allocations, in order to continue to use the same field layouts as today.
The number of unspecified behaviors of field layout being currently exploited is unknown, and disabling the aggressive optimizations might not be sufficient to reproduce the same field layouts with the new code as they were with the old code. The changeset for JDK-8237767 doesn't remove the old code. A VM option should allow users to still use the old code during a transition period (see timeframe below), until the old is eventually removed.
Note that there's no guarantee that such unspecified behaviors of the old code will be back-ported in the new code before the old code is removed.
Specification
UseEmptySlotsInSupers
is a new product VM option, with type boolean and a default value of true, which would disable new optimizations during field layout computations, in order to produce the same layouts as the old code. This option would be supported on the long term with the new code.
UseNewFieldLayout
is a new pre-deprecated product VM option, with a type boolean and a default value of true, which would allow users to still use the old code instead of the new code, in case some unknown differences in behavior between the old and the new code impact them. This option is pre-deprecated because the plan is to remove the old code at some point. The current plan is to have this option pre-deprecated in JDK 15, to make it obsolete in JDK 16 when the old code is removed (before JDK 17, the next LTS release).
Webrev: http://cr.openjdk.java.net/~fparain/jdk_layout/webrev.09c/index.html
- csr of
-
JDK-8237767 Field layout computation overhaul
-
- Resolved
-
- relates to
-
JDK-8330607 Deprecate -XX:+UseEmptySlotsInSupers
-
- Resolved
-