Skip to content

Conversation

@coleenp
Copy link
Contributor

@coleenp coleenp commented Dec 8, 2025


Progress

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

Error

 ⚠️ The pull request body must not be empty.

Warnings

 ⚠️ Patch contains a binary file (src/java.base/share/classes/jdk/internal/icu/impl/data/icudt76b/nfc.nrm)
 ⚠️ Patch contains a binary file (src/java.base/share/classes/jdk/internal/icu/impl/data/icudt76b/ubidi.icu)
 ⚠️ Patch contains a binary file (src/java.base/share/classes/jdk/internal/icu/impl/data/icudt76b/uprops.icu)
 ⚠️ Patch contains a binary file (test/jdk/javax/net/ssl/HttpsURLConnection/crisubn.jks)
 ⚠️ Patch contains a binary file (test/jdk/javax/net/ssl/HttpsURLConnection/trusted.jks)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1775

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/valhalla/pull/1775.diff

@bridgekeeper
Copy link

bridgekeeper bot commented Dec 8, 2025

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

@openjdk
Copy link

openjdk bot commented Dec 8, 2025

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

@openjdk
Copy link

openjdk bot commented Dec 8, 2025

@coleenp this pull request can not be integrated into lworld due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout matias-cds
git fetch https://git.openjdk.org/valhalla.git lworld
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge lworld"
git push

@openjdk openjdk bot added the merge-conflict Pull request has merge conflict with target branch label Dec 8, 2025
void print_elements_on(outputStream* st) {
FlatArrayKlass::cast(real_klass())->oop_print_elements_on(raw_flatArrayOop(), st);
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AOTMapLogger::FakeRefArray has an FakeOop obj_at(int i) method for reading the elements. Do we need an equivalent for FakeFlatArray?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we get away without having it due to the implementation of FlatArrayKlass::oop_print_on?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought it was nicer to have the printing logic in the flatArrayOop.cpp file rather than in some AOT file, so it's more like typeArrayOop. The refArray case wants to save the oops it finds for something.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although I suppose this won't work if the flatArrayKlass has oops (something about read_oop_at())

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code is weird. I don't know this code.

// Save a C heap allocated version of the scalarized signature and store it in the adapter
GrowableArray<SigEntry>* heap_sig = new (mtInternal) GrowableArray<SigEntry>(ces.sig_cc()->length(), mtInternal);
heap_sig->appendAll(ces.sig_cc());
super_method->adapter()->set_sig_cc(heap_sig);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand (yet) why the scalarized versions aren't already archived as part of the existing adapter archiving. Getting them saved/restored in the archive seems like the best approach, with this being a work around until that's sorted

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We explicitly null out the _sig_cc from the archived adapters in AdapterHandlerEntry::remove_unshareable_info as _sig_cc is a new Valhalla thing. It's possible for it to be added to the AOTCache, but we just haven't done the work to save / restore the arrays of SigEntries.

Opened https://bugs.openjdk.org/browse/JDK-8373348 a reminder to update the AOTCache support later


bool CDSConfig::is_dumping_heap() {
if (is_valhalla_preview()) {
// Not working yet -- e.g., HeapShared::oop_hash() needs to be implemented for value oops
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see an implementation of HeapShared::oop_hash() for value oops in this PR. Can you point me at it or is this comment outdated?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is something that doesn't work that for some reason I didn't run into on Friday.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It wasn't the oop_hash() reason that something didn't work, it was the wrong prototype header.

@openjdk openjdk bot removed the merge-conflict Pull request has merge conflict with target branch label Dec 8, 2025
@openjdk openjdk bot added the merge-conflict Pull request has merge conflict with target branch label Dec 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merge-conflict Pull request has merge conflict with target branch

Development

Successfully merging this pull request may close these issues.

2 participants