clinit and threads

[Kevin Rushforth]

Hi Johan,

I don't know whether this work at all, and it might be even more work 
than what you are proposing, but a possible approach would be to create 
a variant of the getToolkit method with a boolean indicating whether to 
create/initialize the Toolkit instance, with a default of "false". 
Something like this:

Toolkit:

public static synchronized Toolkit getToolkit() {
     getToolkit(false);
}

public static synchronized Toolkit getToolkit(boolean create) {
     if (TOOLKIT != null) {
         return TOOLKIT;
     }
     if (!create) throw new IllegalStateException("Toolkit not created");

     // existing code goes here....
}

The PlatformImpl startup code (and maybe a few other cases) would call 
getToolkit(true). Existing code that calls Toolkit.getToolkit would work 
only if the platform was already started, which is proably OK for many 
of the usages.

This presumes that the FX runtime is always started before getting to 
the various places that call getToolkit(), which might or might not be a 
valid assumption. This should not be a problem with proper JavaFX 
applications that aren't trying to be overly clever and do anything 
before the Application is launched. If there are some code paths that 
call getToolkit without the platform being properly started up, they 
would get an ISE. It might be a problem for our test framework (e.g., 
the StubToolkit-based tests). It would need to be tested.

A variation on the above: if most places can safely call the existing 
getToolkit() method, you could flip the default and call 
getToolkit(false) in the (hopefully few) places that you find are called 
from a static initializer.

Anyway, that's all I could come with off the top of my head.

-- Kevin


On 5/3/2018 1:18 PM, Johan Vos wrote:
> Hi,
>
> For a number of reasons, I'm looking into using SubstrateVM to bundle a
> JavaFX application into a native executable. The SubstrateVM relies on an
> AOT that's more aggressive than Gluon VM and it will precompile class
> initializers.
> I clearly see the (performance) benefits of this, but it has also
> consequences that have to be taken into account.
>
> One of those consequences is that threads that are somehow referenced via
> those class initialization code should not be in a started state.
>
> I tweaked a few initializers to avoid doing this, but the biggest impact
> this has so far is on Toolkit.getToolkit().
> This will set the static TOOLKIT field of Toolkit to e.g. QuantumToolkit,
> and a whole bunch of objects become reachable including e.g. HashMap$Node
> hence ThreadPoolExecutor$Worker and a thread is started.
>
> As long as there is no single clinit call that uses Toolkit.getToolkit()
> this is not a problem, but clearly there are class initializers that use
> (indirectly) Toolkit.getToolkit() -- for example, AbstractMasterTimer.java
> has a few booleans that are statically initialized to
> Settings.getBoolean(), which triggers Settings.getInstance(), which uses
> Toolkit.getToolkit()
>
> While it is not impossible to modify those, it's probably some work and I
> wonder if there might be an easier solution?
>
> - Johan