On Thu, 18 Nov 2021 04:13:21 GMT, Jaikiran Pai <[email protected]> wrote:
>> Pretty much what it says. The new option controls a static member in
>> InstanceKlass that's consulted to determine whether the finalization
>> machinery is activated for instances when a class is loaded. A new native
>> method is added so that this state can be queried from Java. This is used to
>> control whether a finalizer thread is created and to disable the `System`
>> and `Runtime::runFinalization` methods. Includes tests for the above.
>
> 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.
-------------
PR: https://git.openjdk.java.net/jdk/pull/6442
