RFR: 8320272: Make method_entry_barrier address shared

Fei Yang fyang at openjdk.org
Mon Nov 20 04:17:33 UTC 2023


On Fri, 17 Nov 2023 22:36:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This seems fine, but you could explain a little more why this is useful for Leyden?  I would think having StubRoutines::method_entry_barrier() would be enough, and that it could reference the existing platform-specific name, minimizing changes.  I don't understand why the storage needs to be shared in StubRoutines::_method_entry_barrier, for example.
>
>> This seems fine, but you could explain a little more why this is useful for Leyden? I would think having StubRoutines::method_entry_barrier() would be enough, and that it could reference the existing platform-specific name, minimizing changes. I don't understand why the storage needs to be shared in StubRoutines::_method_entry_barrier, for example.
> 
> Thank you for looking, Dean. Yes, your suggestion would work too. Leyden code calls StubRoutines::method_entry_barrier() to get address: [SCCache.cpp#L3337](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/SCCache.cpp#L3337)
> But we would need StubRoutines::method_entry_barrier()  implementation for each platform in such case. And having duplication and different names does not feel right for me ;^)

@vnkozlov : Hi, I have tested this on linux-riscv platform. Result looks fine.
Would you mind apply following small add-on change which adds relocation info for this platform too? Thanks.
[16708-riscv.diff.txt](https://github.com/openjdk/jdk/files/13406179/16708-riscv.diff.txt)

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

PR Comment: https://git.openjdk.org/jdk/pull/16708#issuecomment-1818200214


More information about the hotspot-compiler-dev mailing list