Integrated: 8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry

Matias Saavedra Silva matsaave at openjdk.org
Tue Mar 28 19:53:59 UTC 2023


On Mon, 27 Feb 2023 21:37:34 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC port was provided by @reinrich, RISCV was provided by @DingliZhang and @zifeihan, and S390x by @offamitkumar.
> 
> This change supports the following platforms: x86, aarch64, PPC, RISCV, and S390x

This pull request has now been integrated.

Changeset: 3fbbfd17
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3fbbfd17491906d707f73fe6b0db2989363c303a
Stats:     1516 lines in 58 files changed: 1109 ins; 173 del; 234 mod

8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry

Co-authored-by: Richard Reingruber <rrich at openjdk.org>
Co-authored-by: Dingli Zhang <dzhang at openjdk.org>
Co-authored-by: Gui Cao <gcao at openjdk.org>
Co-authored-by: Amit Kumar <amitkumar at openjdk.org>
Reviewed-by: coleenp, dnsimon, fparain, gcao, aph, fyang, amitkumar, lucy

-------------

PR: https://git.openjdk.org/jdk/pull/12778


More information about the serviceability-dev mailing list