RFR: 8337753: Target class of upcall stub may be unloaded

[Jorn Vernee]

On Thu, 8 Aug 2024 10:51:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Can't we do these nasty loads in C++ code and use set_vm_result_2 in UpcallLinker::on_entry?

That's what I tried. I got a ~20% hit to execution time.

> I guess that upcalls are less performance critical

Why so? They are certainly much more rare than downcalls, but when they _are_ used, I think we'd like them to be fast.

> Maybe the C++ code can get optimized better, too.

I [tried](https://github.com/openjdk/jdk/commit/a2614ab77ef0ed493a819b970b31b939126c3da5) optimizing things by moving the accessors to `javaClasses.inline.hpp`, that helped the generated code a bit, but it didn't really improve speed. I think the problem is that we don't know at C++ compile time which barrier we need to use, since the GC is selected at runtime, while we do know when generating the stub. So, if we use C++, there will always be an out-of-line dispatch to the `_load_at` function for the particular GC.

> Some of the DecoratorSet should be applicable and improve performance. If that doesn't help enough, maybe we should implement a dedicated static stub? There's no need to have the code replicated in each upcall stub.

That's a good idea. If we can make that work, I'm all for it.

P.S. giving that a try now.

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

PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2275658037
PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2275861261