On Tue, 28 Apr 2026 04:21:36 GMT, Axel Boldt-Christmas <[email protected]> wrote:
> > Once you have a flattening budget, doesn't this bring up issues similar to > > method inlining on how to spend that budget? For example, should it be > > spent eagerly on the first fields (depth first), or should top-level fields > > be flattened before nested fields (breadth first)? > > I was thinking the same, but more along the lines of a bytes utilization > knapsack problem. We probably don’t have any information about what is good > to flatten unless we add something to the AOT training data. > > But feels like it would add a whole lot of complexity, and seems like a post > 401 RFE. The flattening decision differs from the inlining decision in the fact that it doesn't make recursive decisions. When considering if a field should be flattened or not, the algorithm can only use layouts that have already be computed for this field's value class. Flattening decisions in this class have already been made when the class was loaded. The current implementation of this flattening budget is inherently a greedy algorithm, the budget is being consumed in the order the fields are inserted in the layout, and those insertions are performed from the bigger value to the smaller value. It will prioritize the flattening of a few big values rather than many small values. This aspect of the algorithm was mentioned in the CR. However, it would be difficult to change this without rewriting the whole layout computation algorithm to add more passes over the fields information. It is important to remember that the main purpose of this budget is not to tune the flattening decisions of the JVM, it is a far too coarse tool for that. Its goal is to simply put a limit on how far the JVM will flatten fields to prevent user code from easily reaching JVM internal resources limits and causing a VM crash. Most users will never have to deal with this VM option. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/2372#issuecomment-4359669074
