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

[Johan Sjölen]

On Wed, 8 Oct 2025 20:15:11 GMT, Serguei Spitsyn <sspitsyn 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.
>
>> 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?
> 
> It depends. And no, it is not always 'human' level (debuggers, etc). It is used by profilers as well especially via Instrumentation API. And yes, JVMTI is that it's less performance sensitive than the usual JVM. However, it'd be nice to improve its performance, not degrade. :)

@sspitsyn , the points about detecting null are good. Let me look at those in more detail tomorrow. I need to a bit more fresh. You might be right, `guarantee` might be preferred here.

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

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