8382045: Reduce C strings caching with AOT code in not product VM

[vnkozlov]

AOT stubs caching introduced by JDK-8372617 and AOT code caching for upcoming JEP saves C strings referenced from code so we can use them when loading cached code. Such strings includes C strings collected by calling block_comment() and code_string() using AsmRemarks and DbgStrings classes.

AOT code caching reserve small array with 500 entries in not product VM for C strings (and 200 in product VM). It was enough during Leyden development.

After AOT stub caching was implemented I noticed that we hit this limit when AOT code is also cached. Investigation shows that we generated more than 400 C strings in stubs on Aarch64:

[1.910s][debug][aot,codecache,exit] Wrote 427 C strings of total length 7999 at offset 684616 to AOT Code Cache

Further investigation shows that a lot of them look like this on Aarch64:

[0.018s][trace][aot,codecache,stringtable] add_C_string: [7] 0x0000600003deb040 '0x6000010E4740'

which were created by block_comment() in immediate load MacroAssembler instructions: movptr(), mov_immediate64() and mov_immediate32().

My first intention was to remove block_comment() from these instructions but it only reduce number of cached C strings by half.

The collecting block comments are controlled by CodeBuffer::_collect_comments field which is set when print code VM flags are specified and also when UnlockDiagnosticVMOptions flag is set. AOT caching flags are mostly diagnostic flags and this flag is used in testing triggering collecting block comments even when code printing was not asked.

The check for UnlockDiagnosticVMOptions was added for JDK-8225429: 83377c4

I suggest to skip UnlockDiagnosticVMOptions check for CodeBuffer::_collect_comments when we dump AOT code.

This significantly reduced number of cached C strings:

[1.148s][debug  ][aot,codecache,exit]   Wrote 32 C strings of total length 1635 at offset 635904 to AOT Code Cache

I also increase AOT C strings buffer limit to 2000 in not product VM.

In addition I passed missing strict argument in CodeBlob::as_buffer_blob() otherwise we hit assert in is_buffer_blob() when using -Xlog:aot+codecache+stubs=trace.

Testing: tier1-3,comp-stress

---

• I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

---

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-8382045: Reduce C strings caching with AOT code in not product VM (Enhancement - P4)

Reviewers

• Andrew Dinn (@adinn - Reviewer) 🔄 Re-review required (review applies to 1fa8cc9f)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 30691

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back kvn! 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]

@vnkozlov This change is no longer ready for integration - check the PR body for details.

[openjdk]

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

• hotspot-compiler

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]

Webrevs

• 01: Full - Incremental (d2916734)
• 00: Full (1fa8cc9f)

[adinn]

Looks good

[vnkozlov]

Thank you, @adinn, for review and correction.