While testing JNIPort on Pharo 1.0 and Pharo 1.1, I noticed that in Pharo
1.0, a JVM (a wrapper object for the Java Virtual Machine) could be
initialized in ca. 4 seconds, while this needed 11 to 12 seconds in Pharo
1.1. When I profiled the JVM startup in 1.1, the profile reported that less
than 20% of the time was spent there; the rest was not accounted for in the
report.

In Squeak 4.1, I encountered a deadlock problem related to Squeak's current
WeakRegistry implementation when the JVM is started. This problem
disappeared when I changed the finalizationProcess of WeakArray such that it
runs at systemBackgroundPriority instead of userBackgroundPriority.

Applying the same change to Pharo 1.1 makes a big difference. The JVM starts
in 4.4 seconds, approximately matching the time it takes in Pharo 1.0.

Starting the JVM in Squeak 4.1 is about 20% faster than Pharo 1.1. As the
difference is in the part which is not accounted for by the time profiler,
it is probably due to the differences in the implementation of
WeakIdentityKeyDictionary which have an impact on the performance of the
finalizationProcess.

I am not sure if changing the priority of the finalizationProcess could
possibly break something, and I also do not yet understand why changing the
priority makes such a big difference both in Squeak and Pharo.

How should this issue be handled? Should I add this as issues to the bug
tracking tools for Pharo and Squeak respectively?

Cheers,
Joachim Geidel