clinit and threads
johan.vos at gluonhq.com
Thu May 3 20:18:04 UTC 2018
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
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
While it is not impossible to modify those, it's probably some work and I
wonder if there might be an easier solution?
More information about the openjfx-dev