8367989: Remove InstanceKlass::allocate_objArray and ArrayKlass::allocate_arrayArray #27372

coleenp · 2025-09-18T18:27:14Z

This change removes InstanceKlass::allocate_objArray and has its caller call ObjArrayKlass::allocate_instance directly from oopFactory, like the other array allocations do. See CR for more information why we should have this change. I also removed element_klass_addr() and moved element_klass_offset() to be in a more logical place near element_klass() functions. This upstreams a tiny valhalla diff.
Tested with tier1-4.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8367989: Remove InstanceKlass::allocate_objArray and ArrayKlass::allocate_arrayArray (Enhancement - P4)

Reviewers

Stefan Karlsson (@stefank - Reviewer)
Frederic Parain (@fparain - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27372/head:pull/27372
$ git checkout pull/27372

Update a local copy of the PR:
$ git checkout pull/27372
$ git pull https://git.openjdk.org/jdk.git pull/27372/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27372

View PR using the GUI difftool:
$ git pr show -t 27372

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27372.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-09-18T18:29:27Z

👋 Welcome back coleenp! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-09-18T18:30:44Z

@coleenp This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8367989: Remove InstanceKlass::allocate_objArray and ArrayKlass::allocate_arrayArray

Reviewed-by: stefank, fparain

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 85 new commits pushed to the master branch:

47efe3c: 8343395: SSLLogger doesn't work for formatted messages
bdfe05b: 8368071: Compilation throughput regressed 2X-8X after JDK-8355003
c3aaa87: 8361955: [GCC static analyzer] libjdwp/threadControl.c threadControl_setPendingInterrupt error: dereference of NULL 'node'
... and 82 more: https://git.openjdk.org/jdk/compare/b00e0dae9bbd4bd88f8e7307b7c96688fa3194fe...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2025-09-18T18:31:33Z

@coleenp The following label will be automatically applied to this pull request:

hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2025-09-18T18:35:39Z

Webrevs

stefank · 2025-09-19T08:15:20Z

src/hotspot/share/memory/oopFactory.cpp

+    ArrayKlass* ak = InstanceKlass::cast(klass)->array_klass(CHECK_NULL);
+    return ObjArrayKlass::cast(ak)->allocate_instance(length, THREAD);


Before this change the two if/else branches had a symmetry that is lost with the proposed change. It makes you look at the code and wonder what the reason is for this asymmetry. Could the symmetry be retained by changing this to:

objArrayOop oopFactory::new_objArray(Klass* klass, int length, TRAPS) { ArrayKlass* ak; if (klass->is_array_klass()) { ak = ArrayKlass::cast(klass)->array_klass(CHECK_NULL); } else { ak = InstanceKlass::cast(klass)->array_klass(CHECK_NULL); } return ak->allocate_instance(length, THREAD); }

Or if you dare to use a virtual call instead of the if branch:

objArrayOop oopFactory::new_objArray(Klass* klass, int length, TRAPS) { ArrayKlass* ak = klass->array_klass(CHECK_NULL); return ak->allocate_instance(length, THREAD); }

If the virtual call is unwanted then we could add a new "faster" (unclear how much faster this actually is):

ArrayKlass* Klass::array_klass_fast(TRAPS) { ArrayKlass* ak; if (klass->is_array_klass()) { ak = ArrayKlass::cast(klass)->array_klass(CHECK_NULL); } else { ak = InstanceKlass::cast(klass)->array_klass(CHECK_NULL); } assert(ak == array_klass(), "The two functions should return the same result"); return ak; } ... objArrayOop oopFactory::new_objArray(Klass* klass, int length, TRAPS) { ArrayKlass* ak = klass->array_klass_fast(CHECK_NULL); return ak->allocate_instance(length, THREAD); }

(I've not compiled nor tested the above)

It wasn't really symmetric except number of lines. One branch calls ArrayKlass::allocate_arrayArray, the other calls allocate_instance for ObjArray. Unless I refactor allocate_arrayArray into this, it still won't be symmetrical, and it's quite a bit different in the valhalla repo.

It might make sense to refactor allocate_arrayArray into this though and remove that too.
Yes, I like suggestion #1. There are too many array allocation functions.

It wasn't really symmetric except number of lines.

Given that you refuted my statement about symmetry I want to try to explain what symmetry I saw but you didn't:

The old code called allocate_xArray function in both branches. That was the symmetry. It was quite clear that the two functions accomplished similar goals, in similar ways. Yes, the functions called are named differently, but I didn't talk about absolute symmetry in characters of number of lines.

In the first proposed patch both branches call its corresponding array_klass function, but only one of the legs make it explicit, and the other has that deferred to the call to allocate_xArray function. I find that this kind of asymmetry often hurts readability and makes code harder to maintain. Hence my proposal. My 2c.

Your suggested changes are really good. Thanks.

…ough.

coleenp · 2025-09-19T14:27:20Z

src/hotspot/share/memory/oopFactory.cpp

-    return ArrayKlass::cast(klass)->allocate_arrayArray(1, length, THREAD);
-  } else {
-    return InstanceKlass::cast(klass)->allocate_objArray(1, length, THREAD);
-  }


I suppose this has symmetry in the mainline, except both of these functions do the same thing as ObjArrayKlass.allocate_instance do. The goal is to hide allocate_instance and only make this class a friend, and not InstanceKlass. This isn't the case in the current repository but it is in the valhalla repo and I want them to be the same at this level.

So this isolates the CollectedHeap::array_allocate call to less places now.

stefank

This looks good to me. Please test this thoroughly given the complexity inside the called functions.

coleenp · 2025-09-22T15:57:20Z

Thanks Stefan. I'm running tier1-8 testing now.

coleenp · 2025-09-24T12:51:19Z

Thanks for reviewing Stefan and Fred. Testing was clean.
/integrate

openjdk · 2025-09-24T12:51:54Z

Going to push as commit e8adc1f.
Since your change was applied there have been 121 commits pushed to the master branch:

2313f8e: 8368366: RISC-V: AlignVector is mistakenly set to AvoidUnalignedAccesses
288822a: 8367068: Remove redundant HttpRequest.BodyPublisher tests
f993f90: 8360401: [AIX] java/lang/ProcessBuilder/FDLeakTest/FDLeakTest.java fails since JDK-8210549
... and 118 more: https://git.openjdk.org/jdk/compare/b00e0dae9bbd4bd88f8e7307b7c96688fa3194fe...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-09-24T12:52:01Z

@coleenp Pushed as commit e8adc1f.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8367989: Remove InstanceKlass::allocate_objArray

e1680b1

openjdk bot added hotspot [email protected] rfr Pull request is ready for review labels Sep 18, 2025

stefank reviewed Sep 19, 2025

View reviewed changes

coleenp added 2 commits September 19, 2025 12:17

Stefan's suggestion openjdk#1.

f4f1d28

Use virtual function rather than if statement, still need one cast th…

cfa036b

…ough.

coleenp commented Sep 19, 2025

View reviewed changes

coleenp mentioned this pull request Sep 19, 2025

8367415: Fully encapsulate array allocation in oopFactory openjdk/valhalla#1602

Closed

1 task

openjdk bot changed the title ~~8367989: Remove InstanceKlass::allocate_objArray~~ 8367989: Remove InstanceKlass::allocate_objArray and ArrayKlass::allocate_arrayArray Sep 19, 2025

stefank approved these changes Sep 22, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Sep 22, 2025

fparain approved these changes Sep 22, 2025

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Sep 24, 2025

openjdk bot closed this Sep 24, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Sep 24, 2025

coleenp deleted the oopFactory branch September 24, 2025 13:01

		ArrayKlass* ak = InstanceKlass::cast(klass)->array_klass(CHECK_NULL);
		return ObjArrayKlass::cast(ak)->allocate_instance(length, THREAD);

8367989: Remove InstanceKlass::allocate_objArray and ArrayKlass::allocate_arrayArray #27372

8367989: Remove InstanceKlass::allocate_objArray and ArrayKlass::allocate_arrayArray #27372

Uh oh!

Conversation

coleenp commented Sep 18, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Sep 18, 2025

Uh oh!

openjdk bot commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlbridge bot commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

stefank Sep 19, 2025

Choose a reason for hiding this comment

Uh oh!

coleenp Sep 19, 2025

Choose a reason for hiding this comment

Uh oh!

coleenp Sep 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stefank Sep 19, 2025

Choose a reason for hiding this comment

Uh oh!

coleenp Sep 19, 2025

Choose a reason for hiding this comment

Uh oh!

coleenp Sep 19, 2025

Choose a reason for hiding this comment

Uh oh!

stefank left a comment

Choose a reason for hiding this comment

Uh oh!

coleenp commented Sep 22, 2025

Uh oh!

coleenp commented Sep 24, 2025

Uh oh!

openjdk bot commented Sep 24, 2025

Uh oh!

openjdk bot commented Sep 24, 2025

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

coleenp commented Sep 18, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Sep 18, 2025 •

edited

Loading

openjdk bot commented Sep 18, 2025 •

edited

Loading

mlbridge bot commented Sep 18, 2025 •

edited

Loading

coleenp Sep 19, 2025 •

edited

Loading