Summary: | fourthTier: CodeBlock should be RefCounted | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Filip Pizlo <fpizlo> | ||||
Component: | JavaScriptCore | Assignee: | Filip Pizlo <fpizlo> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | barraclough, ggaren, mark.lam, mhahnenberg, msaboff, oliver, sam | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 112839 | ||||||
Attachments: |
|
Description
Filip Pizlo
2013-05-04 13:43:53 PDT
Can we use GC for this instead? Inside the GC heap, it's easier when GC objects point to other GC objects. (In reply to comment #1) > Can we use GC for this instead? Inside the GC heap, it's easier when GC objects point to other GC objects. Probably, eventually. But right now CodeBlock has a weird relationship with the GC - the GC does have a say in when a CodeBlock dies but not in the usual sense of tracing - so we'll have to be careful when we do that. There's also the issue that how a CodeBlock is traced depends on who owns it (either Executable or the GC itself), so it's not like making it GC'd would simplify its visit methods. For now, I don't see a clear benefit to making CodeBlock GC'd. It's true that doing so would mean that Executable would not have to be destructible, but I think that's really the only benefit. On the other hand, there is a clear benefit to making it ref-counted. Created attachment 201308 [details]
the patch
Not setting r? yet because I'm still running tests.
(In reply to comment #3) > Created an attachment (id=201308) [details] > the patch > > Not setting r? yet because I'm still running tests. It's perf neutral. Comment on attachment 201308 [details]
the patch
r=me
Landed in http://trac.webkit.org/changeset/149860 |