JDK-8207343 : Automate vtable/itable stub size calculation
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-07-16
  • Updated: 2024-01-16
  • Resolved: 2018-09-03
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 11 JDK 12
11.0.2Fixed 12 b10Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
A vtable/itable stub consists of the instance data and an immediately following CodeBuffer. Unfortunately, the required space for the code buffer varies, depending on the setting of compile time macros (PRODUCT, ASSERT, ...) and of command line parameters. Actual data may have an influence on the size as well.

A simple approximation for the VtableStub size would be to just take a value "large enough" for all circumstances - a worst case estimate. As there can exist many stubs - and they never go away - we certainly don't want to waste more code cache space than absolutely necessary.

As of now, a platform specific function estimates a size limit based on sample code emitted at a certain point in time. This is regarded "not future proof".

A different approach is needed which, as far as possible, should be independent from or adaptive to code size variations. These variations may be caused by changed compile time or run time switches as well as by changed emitter code.

Here is the idea:
For the first stub we generate, we allocate a "large enough" code buffer. Once all instructions are emitted, we know the actual size of the stub. Remembering that size allows us to allocate a tightly matching code buffer for all subsequent stubs. That covers all "static variance", i.e. all variance that is due to compile time macros, command line parameters, machine capabilities, and other influences which are immutable for the life span of the vm.

Life isn't always that easy. Code size may depend on actual data, "load constant" being an example for that. All code segments with such "dynamic variance" require additional care. We need to know or estimate the worst case code size for each such segment. With that knowledge, we can maintain a "slop counter" in the platform-specific stub emitters. It accumulates the difference between worst-case and actual code size. When the stub is fully generated, the actual stub size is adjusted (increased) by the slop counter value.

As a result, we allocate all but the first code buffers with the same, tightly matching size.
Comments
Fix Request - This issue was originally filed as enhancement - It is worth to be downported because + it removes the risk of stub size miscalculation completely + it makes platform-specific, static size guesses obsolete + it fixes stale size guesses on several platforms (try java -XX:+DebugVtables -version with a non-product build). - The risk is considered to be at the high end of low. "At the high end" only because it affects product builds. - The changeset applies cleanly to jdk-updates/jdk11u as of October 26, 2018 - The change requires two follow-up changes (JDK-8210355 and JDK-8210357) ti fix minial and Zero build problems
26-10-2018

Most recent webrev: http://cr.openjdk.java.net/~lucy/webrevs/8207343.04/
04-09-2018

URL: http://hg.openjdk.java.net/jdk/jdk/rev/54b344d9dd4e User: lucy Date: 2018-09-03 07:49:21 +0000
03-09-2018

http://cr.openjdk.java.net/~lucy/webrevs/8207343.01/
13-08-2018