Tobias Hartmann

All tests passed.

This caused a regression, see [JDK-8343925](https://bugs.openjdk.org/browse/JDK-8343925). You might want to consider a quick [backout](https://openjdk.org/guide/#backing-out-a-change).

Don't we already have such error reporting code in `Disassembler::load_library`? https://github.com/openjdk/jdk/blob/c33c1cfe7349ac657cd7bf54861227709d3c8f1b/src/hotspot/share/compiler/disassembler.cpp#L863

> but since nullptr is passed at [src/hotspot/share/compiler/disassembler.hpp#L66](https://github.com/openjdk/jdk/blob/c2d76f9844aadf77a0b213a9169a7c5c8c8f1ffb/src/hotspot/share/compiler/disassembler.hpp#L66), that reporting doesn't actually work. Right, it will be set to `tty` when Verbose is true: https://github.com/openjdk/jdk/blob/c2d76f9844aadf77a0b213a9169a7c5c8c8f1ffb/src/hotspot/share/compiler/disassembler.cpp#L780 Thanks for the additional details...

> @TobiHartmann how much should he invest in this now? An alternative is just tackling all the other cases later. What do you think? Yes, agreed. Let's handle this later....

> I think it may be possible for users to create a Object::hashCode site with a constant receiver that is of a specialized class that overrides hashCode. Yes, I think...

I can run our internal performance testing with this but it currently fails to build on AArch64: ``` [2025-12-03T11:49:29,644Z] * For target hotspot_variant-server_libjvm_objs_c1_LIRAssembler_aarch64.o: [2025-12-03T11:49:29,644Z] /System/Volumes/Data/mesos/work_dir/slaves/da1065b5-7b94-4f0d-85e9-a3a252b9a32e-S5842/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/a3ab2e9e-0898-4ceb-94ab-4f606db9de4d/runs/44169997-4fbe-4f98-98b9-d11781843c5e/workspace/open/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp:2739:18: error: lambda capture 'op' is...

Thanks, still fails though: ``` [2025-12-04T13:35:07,965Z] * For target hotspot_variant-server_libjvm_objs_c1_MacroAssembler_aarch64.o: [2025-12-04T13:35:07,965Z] /opt/mach5/mesos/work_dir/slaves/da1065b5-7b94-4f0d-85e9-a3a252b9a32e-S11677/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/aaf0c312-b425-4910-a568-48e356b81714/runs/ffe8e70a-35bd-4ae4-bed8-85bd71130e51/workspace/open/src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp: In member function 'void C1_MacroAssembler::save_profile_rng()': [2025-12-04T13:35:07,965Z] /opt/mach5/mesos/work_dir/slaves/da1065b5-7b94-4f0d-85e9-a3a252b9a32e-S11677/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/aaf0c312-b425-4910-a568-48e356b81714/runs/ffe8e70a-35bd-4ae4-bed8-85bd71130e51/workspace/open/src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp:302:54: error: 'profile_rng_offset' is not a member of 'JavaThread' [2025-12-04T13:35:07,965Z] 302 |...

That was on Linux AArch64. Let me re-run.

Ah, I think the problem is that there are merge conflicts with master. Could you please resolve them?