-
Enhancement
-
Resolution: Fixed
-
P4
-
11, 12
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8213078 | 11.0.2 | Lucy Schmidt | P4 | Resolved | Fixed | b02 |
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.
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.
- backported by
-
JDK-8213078 Automate vtable/itable stub size calculation
- Resolved
- relates to
-
JDK-8210355 Minimal and Zero non-PCH builds fail after JDK-8207343 (Automate vtable/itable stub size calculation)
- Resolved
-
JDK-8210357 Zero builds fail after JDK-8207343 (Automate vtable/itable stub size calculation)
- Resolved
-
JDK-8234794 AArch64: runtime/memory/ReadFromNoaccessArea.java crashes
- Resolved
-
JDK-8323741 Improve automated vtable/itable stub size calculation
- Open
-
JDK-8323122 AArch64: Increase itable stub size estimate
- Resolved
(1 relates to)