Closed Bug 625145 Opened 14 years ago Closed 6 years ago

Investigate performance of GCWeakRef

Categories

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

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: lhansen, Unassigned)

References

Details

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?
Target Milestone: --- → Future
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.
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.
Blocks: 645018
Blocks: 647160
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.
Flags: flashplayer-qrb+
Tamarin is a dead project now. Mass WONTFIX.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Tamarin isn't maintained anymore. WONTFIX remaining bugs.
You need to log in before you can comment on or make changes to this bug.