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

[Frederic Parain]

On Fri, 6 Feb 2026 19:31:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - Comments update
>>  - Rename new_default_refArray to new_refArray with overload
>>  - Fixes issues mentioned in reviews
>>  - Remove force_refarray and add array klass creation from ArrayDescription
>>  - Fix merge
>>  - Merge remote-tracking branch 'upstream/lworld' into refarray_factory
>>  - Revert foreign methods signature changes
>>  - Foreign API and other fixes
>>  - CI fixes
>>  - More fixes in serviceability code
>>  - ... and 2 more: https://git.openjdk.org/valhalla/compare/dbed07f5...bd5f33d0
>
> src/hotspot/share/cds/cdsProtectionDomain.cpp line 332:
> 
>> 330:   if (_shared_jar_manifests.resolve() == nullptr) {
>> 331:     oop sjm = oopFactory::new_refArray(
>> 332:         vmClasses::Jar_Manifest_klass(), size, ArrayKlass::ArrayProperties::DEFAULT, CHECK);
> 
> Since there have been several of these added, I would like to see a new oopFactory::new_default_refArray(), or even an overload of new_refArray without the DEFAULT properties.  Internally in the JVM, they should all have default properties, so only called from some Java-facing api would they not be default.

Overload method added.

> src/hotspot/share/ci/ciArray.cpp line 66:
> 
>> 64:     {
>> 65:       if (ary->is_refArray()) {
>> 66:         assert(ary->is_objArray(), "");
> 
> Is this not given by the type system so unnecessary to assert?

Fixed.

> src/hotspot/share/ci/ciArray.cpp line 76:
> 
>> 74:         JavaThread* THREAD = CompilerThread::current();
>> 75:         oop elem = flatary->obj_at(index, THREAD);
>> 76:         if (HAS_PENDING_EXCEPTION) {
> 
> This is odd. The compiler cannot create exceptions because it can't call Java code (nor can it allocate?).  Should this be CATCH instead?

The calls to element_value_impl() are guarded by VM_ENTRY_MARK, so this code is executed when the CompilerThread is _in_vm.
In case of a pending exception, the code clears the exception and returns an invalid constant, delegating the handling of the situation to the caller, which is free to opt for a different approach or to simply bail out.
This behavior was discussed with the compiler team.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/2033#discussion_r2784202562
PR Review Comment: https://git.openjdk.org/valhalla/pull/2033#discussion_r2784204843
PR Review Comment: https://git.openjdk.org/valhalla/pull/2033#discussion_r2775893435