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