Priority of WeakArray finalizationProcess
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
thanks for this report. Yes if you can add a bug report this would be great. Stef On Jun 12, 2010, at 9:16 PM, Joachim Geidel wrote:
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
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Am 12.06.10 21:51 schrieb Stéphane Ducasse:
thanks for this report. Yes if you can add a bug report this would be great.
Stef
On Jun 12, 2010, at 9:16 PM, Joachim Geidel wrote:
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.
http://bugs.squeak.org/view.php?id=7546 0007546: WeakRegistry deadlock during finalization http://code.google.com/p/pharo/issues/detail?id=2551 Issue 2551: Performance degradation of WeakRegistry in Pharo 1.1
On Jun 13, 2010, at 10:32 AM, Joachim Geidel wrote:
Am 12.06.10 21:51 schrieb Stéphane Ducasse:
thanks for this report. Yes if you can add a bug report this would be great.
Stef
On Jun 12, 2010, at 9:16 PM, Joachim Geidel wrote:
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.
http://bugs.squeak.org/view.php?id=7546 0007546: WeakRegistry deadlock during finalization
http://code.google.com/p/pharo/issues/detail?id=2551 Issue 2551: Performance degradation of WeakRegistry in Pharo 1.1
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
participants (2)
-
Joachim Geidel -
Stéphane Ducasse