On Sat, 25 Apr 2026 13:27:24 GMT, Vladimir Kozlov <[email protected]> wrote:
>> src/hotspot/share/code/aotCodeCache.cpp line 3719:
>>
>>> 3717: if (UseG1GC) {
>>> 3718: G1BarrierSetC1* bs =
>>> (G1BarrierSetC1*)BarrierSet::barrier_set()->barrier_set_c1();
>>> 3719:
>>> ADD_EXTERNAL_ADDRESS(bs->pre_barrier_c1_runtime_code_blob()->code_begin());
>>
>> `set_c1_stubs_complete` and `set_c2_stubs_complete` can happen concurrently.
>> Right now it is not a concern because c2 is not adding any external address.
>> But it it also adds any external address, then there could be race in adding
>> the address to `_extrs_addr` array and the `_hash_table`.
>
>> set_c1_stubs_complete and set_c2_stubs_complete can happen concurrently.
>
> No, because the same lock `CompileThread_lock` is used to schedule
> initialization of both compilers - see
> `AbstractCompiler::should_perform_init()`.
> But the order could be different during assembly and production which will
> cause issue. That is why I had different buffers in original changes:
> _C1_blobs and _C2_blobs.
There are already many external addresses added to the external address list
that are C1- and C2-specific. However, in almost all cases these addresses
reference named external C functions/data. They can be (and are) safely added
underneath `AOTCodeAddressTable::init_extrs()` i.e. before C1 or C2 stub
generation commences.
The source of potential problems is the barrier-specific external addresses
that are only available once when we perform GC barrier stub generation. At
present this only applies with C1 stubs. Barrier code that the GC calls out to
which is specific to the current C1 GC barrier are tracked during C1 runtime
stub generation and their addresses get added to the external address table. We
currently register them by shoe-horning a few extra externals adds into
`AOTCodeAddressTable::set_c1_stubs_complete()` i.e. at the point where the C1
stub generation is closed.
Note that the addresses being registered are not actually external C functions
or data. They are addresses of stub code written into the C1 runtime code
buffer. The only reason they don't have a slot in the enumerated stubs/entries
address table is that we don't (currently?) manage generation and/or recording
of these barrier stubs using the templates defined in `stubDeclarations.hpp`.
If we ever need to add C2-specific addresses then doing this in
`AOTCodeAddressTable::set_c2_stubs_complete()` would be problematic because the
order in which they get added to the externals table would not be determinate.
Luckily, at present all the C2-related addresses are available for registration
under `AOTCodeAddressTable::init_extrs()`.
I think in the longer term we should probably handle this by declaring all the
barrier stubs and their entries in `stubDeclarations.hpp` (or possibly
stubDeclarations_<arch>.hpp) so that the relevant entry addresses can be
inserted into the stubs table with well-defined offsets/indexes, avoiding any
dependence on timing of generation. That would also allow us to save and
restore the GC stubs (which we currently cannot do).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/30778#discussion_r3196333268
