Created attachment 238992 [details] Patch The garbage collection function of process shared locks, pshared_gc, is called whenever a process shared lock is destroyed. The GC function has a loop which checks entries in a hashmap of linked lists, looping through all registered locks. If a process has a lot of process shared locks, like more than a few hundred, the GC function causes destruction of these locks to take a long time (exponential). This is noticeable especially if many locks are to be destroyed at the same time. There are probably multiple solutions for this, like calling the GC function only every X lock destruction, by having a time limit or by calling it upon some other event. The provided patch limits how often the GC function can run to at most every 25 milliseconds per process. If i understand it correctly, the only potential GC required after lock destruction should be in other processes, which have their own timers. Best regards Atle
Assign. Delete the [patch] convention as it has been obsoleted by Bugzilla understanding which attachments are patches.
In principle, I agree with this tweak. I have a suggestion, please record the time of the finish of the last gc, instead of start. Otherwise, I suspect it still would allow for too much gcing in some situations.
Created attachment 245177 [details] Patch with saving last timestamp after iteration instead of before Thanks for the suggestion. I've moved the store of the last iteration time to after the GC-ing. Now, in the situation of GC-ing being slow, we will still wait a consistent amount of time before doing it again.