[lworld] RFR: 8375306: [lworld] Investigate alternatives to flatArrayOopDesc::obj_at implementation

[Frederic Parain]

On Wed, 4 Feb 2026 14:41:09 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> First batch of changes to remove potentially dangerous calls to objArrayOopDesc::obj_at().
> Changes are more extensive than intended. In most cases, code modifications consist in using a refArrayOop type instead of a objArrayOop type, because most of the arrays the JVM deals with for its own purpose are always reference arrays (because they are arrays of identity type elements). The patch also adds a new API allowing the VM to request the allocation of a reference array.
> Code dealing with user provided arrays must be ready to handle exceptions when accessing objArrays.
> 
> This is a short term fix, fixing a few bugs, and trying to make the code more robust using the meta-data types. For the long term, a better solution is needed. Accesses to both arrays and fields are becoming more and more complex because of the introduction of flattening, multiple layouts, additional properties. Forcing enforcement at each access would be expensive and wasteful, as the JVM usually operates on well-known objects or arrays. But because of the increasing complexity, having a way to quickly check the validity of an access would help making the VM code more robust.

There are so many places where obj_at() and obj_at_put() are used, and so many different contexts in which they are called that this PR is no trying to fix all of them. The intent is to provide a better internal API to allow use sites to write a safer and more explicit code about array creation and array accesses.

All reference array creations that have been updated in this CR are using the DEFAULT set of array properties, because this is why legacy code was used to have. But it doesn't mean that reference arrays and DEFAULT array properties must always be tied together. For instance, it makes sense to create a reference array of null-free elements. So I think keeping an ArrayProperty argument in the array factory method is important. That being said, the case of creating a reference array with DEFAULT array properties is so common, that it probably deserves a dedicated factory method, like `oopFactory::new_default_refArray(Klass* klass, int length, TRAPS)`, where the DEFAULT array properties set is automatically selected.

I agree that the `force_refarray` parameter could be removed and its setting be handled the way you did in your code. I'll rewrite this patch to use your solution.

Thank you for your feedback.

In the new version, the force_refarray flag is gone.

Instead, there's now two ways get an array klass.
  1 - just as before, by specifying an ArrayProperties argument and let the JVM decide of the layout
  2 - by specifying an ArrayDescription argument (which includes the kind of array and the layout), which is validated and applied without going through the layout selection algorithm used in option 1

This second option provides more flexibility to the VM to control the kind of array it creates.

It is true that currently most, if not all, of the arrays created by the JVM are using the default set of properties. But it is likely to change when the new arrays will become available. Many of these arrays are good candidate for being null-free arrays or frozen arrays.
So, I'd prefer to keep the more generic name `oopFactory::new_refArray()` for the most generic method able to handle all reference array creations with the properties argument, and keep the more precise name for the more limited case of an array with the default set of properties.

Renaming done.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/2033#issuecomment-3860929735
PR Comment: https://git.openjdk.org/valhalla/pull/2033#issuecomment-3862734683
PR Comment: https://git.openjdk.org/valhalla/pull/2033#issuecomment-3871980373
PR Comment: https://git.openjdk.org/valhalla/pull/2033#issuecomment-3873466293