On Wed, 8 Oct 2025 20:15:11 GMT, Serguei Spitsyn <[email protected]> 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
