On Thu, 18 Nov 2021 05:20:02 GMT, Stuart Marks <sma...@openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/ref/Finalizer.java line 195:
>>
>>> 193:
>>> 194: static {
>>> 195: if (Holder.ENABLED) {
>>
>> Hello Stuart,
>> My understanding of the the lazy `Holder` is that it's there to delay the
>> static initialization of the code that's part of the `Holder`. In this case
>> here, the `Holder` is being used right within the `static` block of the
>> `Finalizer` class, that too as the first thing. In this case, is that
>> `Holder` class necessary?
>
> Huh, good catch! This was mostly left over from an earlier version of the
> flag that used system properties, which aren't initialized until after the
> Finalizer class is initialized.
>
> It might be the case that the Holder can be removed at this point, since the
> finalization-enabled bit is no longer in a system property and is in a native
> class member that should be available before the VM is started.
>
> I say "might" though because this occurs early in system startup, and weird
> things potentially happen. For example, suppose the first object with a
> finalizer is created before the Finalizer class is initialized. The VM will
> perform an upcall to Finalizer::register. An ordinary call to a static method
> will ensure the class is initialized before proceeding with the call, but
> this VM upcall is a special case.... I'll have to investigate this some more.
@stuart-marks not sure I see how anything is different here compared to the
existing logic. The `Finalizer` class is explicitly initialized quite early in
the init process, but if a preceding class's initialization created an object
with a finalizer then that same upcall would be involved.
-------------
PR: https://git.openjdk.java.net/jdk/pull/6442
