Open Bug 749784 Opened 13 years ago Updated 2 years ago

investigate using the GC fast marking path in lieu of representing JS heap in the CC graph

Categories

(Core :: Cycle Collector, defect)

Product:
Core
Component:
Cycle Collector
Type:
defect

Tracking

()

Project Flags:
blocking-kilimanjaro +

People

(Reporter: mccr8, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

add support for CC color marking to the GC
(deleted), patch
Details | Diff | Splinter Review
Building the cycle collector graph representation of the JS heap involves a lot of inefficient callbacks. We may be able to just trace the heap directly using the fast marking path to speed up CCs that involve a lot of JS.
Attachment #619676 - Attachment description: allow us to horribly alter GC behavior for the GC, experimental WIP → allow us to horribly alter GC behavior for the CC, experimental WIP
I talked to Bill a bit about how to make the GC marking code better. This alters the behavior less. It covers flooding black and white in the CC, but not the initial color changing, which Bill suggests we can do by operating directly on the mark bits.
Attachment #619676 - Attachment is obsolete: true
blocking-kilimanjaro: --- → +
Assignee: continuation → nobody
Severity: normal → S3
Component: XPCOM → Cycle Collector
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: