On Thu, 18 Nov 2021 07:13:55 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> 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. Do we even have to have a flag on Java side? It looks like these calls are only done as the upcalls from VM, so we might just keep the flag on VM side? ------------- PR: https://git.openjdk.java.net/jdk/pull/6442
