RFR: 8367656: Refactor Constantpool's operand array into two [v5]

[Johan Sjölen]

On Fri, 19 Sep 2025 02:45:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>One query: have you done any performance measurements for this change? I'm a little concerned that the insertion iterator and the internal array management is now more heavyweight than the old array management.

I haven'e done any performance testing. I was considering doing so, but the majority of the work that has potentially been slowed down is when redefining classes via JVMTI, as this is when we got to do what essentially boiled down to a `memcpy`. My understanding of JVMTI is that it's less performance sensitive than the usual JVM, as it's only used or tooling on a 'human' level (debuggers, etc). Is that understanding correct?

Regardless, I'll have a look at doing some coarse-grained profiling via Aurora, and also have a look at the generated assembly. The goal of putting some of the functions in the inline file was to give enough context to the compiler so that it can do a good job of optimizing the code, we'll see if that was actually the case.

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

PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3311891616