625145 - Investigate performance of GCWeakRef

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Garbage Collection (mmGC), defect)

Description

[Lars T Hansen]

GCWeakRef needs to be cheap, but what's the cost?  What's the cost under heavy pressure (tens of thousands of objects), and in a very varying object population?  What's the impact on the GC's incrementality, for that matter?  Are the data structures (linear hashtables, if memory serves) appropriate?  Is there room for improvement?

Comment 1

[Tommy Reilly]

It was designed to be fast but its never been put under the microscope and optimized.   The only thing I questioned from a cursory glance is the fact that we walk all the weak refs in Finalize _and_ we call ClearWeakRef when weakly referenced objects are found during finalization, seems duplicitous.

The GCHashtable average probe depth has been known to get bad in the profiler under the constant add/remove traffic, this could affect the weak ref table too.

A weak dictionary abusing benchmark would probably be the first order of business.

Comment 2

[Lars T Hansen]

An interesting observation about finalization.  Presumably changing finalization semantics will really shake up this code so it may not be worth worrying about right now, but interesting point nonetheless.

Comment 3

[Lars T Hansen]

Bug 647155 was logged in response to Tommy's remark about duplicitousness above, I rediscovered the problem while working on finalization cleanup.  Seems like a no-brainer to clean it up.

Comment 4

[Sylvestre Ledru [:Sylvestre]]

Tamarin is a dead project now. Mass WONTFIX.

Comment 5

[Sylvestre Ledru [:Sylvestre]]

Tamarin isn't maintained anymore. WONTFIX remaining bugs.