[External] : Re: premain: Possible solutions to use runtime G1 region grain size in AOT code (JDK-8335440)
Andrew Dinn
adinn at redhat.com
Tue Aug 20 14:11:43 UTC 2024
On 15/08/2024 23:30, Vladimir Kozlov wrote:
>> Why you still use base+offsets for constants address? Is it for Aarch64?
>>
>> What I want is something like this:
>>
>> static address grain_shift_address() { return
>> &_aot_runtime_constants::_grain_shift; }
Hmm, I thought I had made the changes to use a direct address but they
were not in the aarch64 version I pushed. I have pushed a new version
that fixes the macroassembler and g1 stubs to load the field address as
a constant. I removed the xxx_offset() methods from AOTRuntimeConstants
and replaced them with xxx_address() methods to make sure it can only be
done that way.
>> And you will not need `#if INCLUDE_CDS` if you put AOTRuntimeConstants
>> into SCCache.cpp.
Yes, SCCache.hpp/cpp is a much better place for this class than
stubRoutines.hpp/cpp. The need to generate AOT code variants that employ
constants from the current runtime is not specific to stubGenerator
stubs. However, it always relates to use of the AOT cache.
>> I don't see the need to separate create_field_address_list() code from
>> field_addresses_list().
Sorry, this was a hangover from an initial implementation. The getter
now returns the array from a static field initialized in SCCache.cpp.
>> Add assert to field_addresses_list() to check that values are
>> initialized.
>
> Actually you don't need assert since we need only addresses of fields.
Left as is.
> I don't see use of aot_runtime_constants_at() anymore.
It is redundant and has been removed.
> Also why you need aot_runtime_constants()? Why not have
> _aot_runtime_constants as static field of AOTRuntimeConstants class
> which you can initialize in (again) SCCache.cpp?
Agreed. The static singleton is now only used internally to the class.
So, we no longer need aot_runtime_constants() any more.
Latest code:
https://github.com/adinn/leyden/compare/premain...adinn:leyden:JDK-8335440-load-via-codecache?expand=1
This passes tier1 tests on aarch64 and successfully improves performance
for the javac benchmark.
regards,
Andrew Dinn
-----------
More information about the leyden-dev
mailing list