Anonymous | Login | 04-12-2021 16:12 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
0007546 | [Squeak] Kernel | major | always | 06-13-10 08:08 | 02-06-11 23:48 | ||||
Reporter | JoachimGeidel | View Status | public | ||||||
Assigned To | leves | ||||||||
Priority | normal | Resolution | fixed | ||||||
Status | closed | Product Version | 4.1 | ||||||
Summary | 0007546: WeakRegistry deadlock during finalization | ||||||||
Description |
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. However, normal processes (with priority 40) could starve the finalization process if it's priority were <= 40 (#systemBackgroundPriority is 20). To reproduce, load JNIPort into Squeak 4.1, and start a JVM as described on http://www.squeaksource.com/JNIPort.html. [^] At the point where the deadlock occurs, the finalizationProcess sends #wait to the accessLock of WeakRegistry, then the Process which initializes the JVM waits on the same Semaphore until the process is interrupted by a user interrupt. After proceeding, the interrupted process proceeds, signals the accessLock, and only after this, the finalizationProcess finishes finalizeValues and signals the accessLock. Lowering the priority of the finalizationProcess works around this problem, but probably simply by completely stopping finalization until the JVM initialization has finished. |
||||||||
Additional Information | |||||||||
Attached Files | |||||||||
|
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
37 total queries executed. 31 unique queries executed. |