JDK-8284578 : Relax InterpreterCodelet stub alignment
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11,17,18,19
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-04-08
  • Updated: 2023-11-30
  • Resolved: 2022-04-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 19
19 b19Fixed
Related Reports
Relates :  
JDK-8284533 - Improve InterpreterCodelet data footprint
Relates :  
JDK-8321137 - Relax ICStub alignment
Description
InterpreterCodelet is aligned by CodeEntryAlignment (CAE) twice. First, the entire stub is aligned, which aligns its data section. Then, the code section in the stub is aligned. Since CAE is usually larger than the size of InterpreterCodelet, we are wasting quite a bit of space for each codelet.

In the extreme cases, like PPC that defaults to CAE=128, we have 16 bytes of codelet data effectively taking 128 bytes! 

This can be made better by relaxing the InterpreterCodelet stub alignment to, say, HeapWordSize.
Comments
[17u][~goetz] Yes, I got no visible effect in benchmarks, closed the PR in 17u as well.
12-01-2023
[17u] I still think the benefit of this change is too small to backport it. I remove the tag in the meantime to get it out of my filters.
04-01-2023
JDK-8283298 is already backported so udated PR does not contain its part. The risk is small as I don't see a danger of getting a layout with overlapped codelets. There is a chance however that performance impact is zero or negative, I'm collecting some data. Absolute footprint saving is tiny but interpreter performance is important for short living applications, for startup, for latency during deoptimizations.
09-12-2022
An argument in favor of improving interpreter performance is that microservices that run for short periods of time spent significant time in the interpreter.
08-12-2022
Hi [~dchuyko], I think the benefit of this, i.e., optimizing the interpreter, seems rather small to justify a backport, especially as it is a mixture of parts of several changes and so as such untested in 19. What is the expected improvement? Save space in the code cache? Runtime? Startup? What is the risk? Also, please mention that you include parts of JDK-8283298 in the fix request comment above. Best regards, Goetz
08-12-2022
Fix Request (17u): This a performance improvement to interpreter (memory layout), and addresses are calculated more accurate. Original patch was only aligned to a slightly different context without significant modifications. PR: https://github.com/openjdk/jdk17u-dev/pull/753 Testing: tier1, tier2 on x86 and aarch64.
10-11-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/753 Date: 2022-09-29 11:45:32 +0000
29-09-2022
Changeset: 2241a057 Author: Aleksey Shipilev <shade@openjdk.org> Date: 2022-04-14 07:30:37 +0000 URL: https://git.openjdk.java.net/jdk/commit/2241a057050ed521cfbfbe8a758353e621dee15f
14-04-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/8159 Date: 2022-04-08 11:45:13 +0000
08-04-2022