Tom Rodriguez

No rush on any of this, but I just wanted keep you posted on what I'm seeing with our testing. As far as the truffle part, you can at least...

Thanks. I'll launch our internal gate and see where we stand on testing.

Mostly the gate looks good. There are problems with the amd64 truffle barrier that I'm fixing. I don't know if I can push here but I can provide the patch...

I'd like to clarify a bit what's actually done here. Some JVMCI compilation can have an associated instance of InstalledCode that has value written into it by hotspot that point...

We'll address this flag in https://bugs.openjdk.org/browse/JDK-8357619 as I think it no longer serves a purpose other than confusion. Passing false should be correct, but I think we'll probably end up...

So this copying keeps the same compile_id, which sort of makes sense but it's also potentially confusing. What's the plan for how this interacts with flags like PrintNMethods and JVMTI...

> If it is moved, the [CompiledMethodUnload](https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#CompiledMethodUnload) event is sent, followed by a new CompiledMethodLoad event. > we now have 2 nmethods alive with the same compile_id which could be...

I'm already looking into this and as you say it's more complicated than just bumping to RELEASE260. We don't want to access jdk.graal.compiler.graphio.parsing.model from the JDK as there is already...

I've got a working update at https://github.com/oracle/graal/pull/11421 including a workaround for the GraalVM JDK 24 IGV problem. Could you test it out?

Thanks for that fix. I'll try that out. If it can resolve our GraalVM 24 jargraal issue that would be great.