Bug 181811 - MaterializeNewObject expects the JSFinalObject allocator to be non-null.
Summary: MaterializeNewObject expects the JSFinalObject allocator to be non-null.
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Keith Miller
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-18 13:48 PST by Keith Miller
Modified: 2018-03-10 15:47 PST (History)
6 users (show)

See Also:

Attachments
Patch (1.90 KB, text/plain)
2018-01-18 13:58 PST, Keith Miller 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Keith Miller 2018-01-18 13:48:50 PST 
MaterializeNewObject expects the JSFinalObject allocator to be non-null.
Comment 1 Keith Miller 2018-01-18 13:58:58 PST 
Created attachment 331658 [details]
Patch
Comment 2 Saam Barati 2018-01-18 16:18:23 PST 
Comment on attachment 331658 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=331658&action=review

> Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:9888
> +                BlockDirectory* cellAllocator = subspaceFor<JSFinalObject>(vm())->allocatorForNonVirtual(allocationSize, AllocatorForMode::EnsureAllocator);

This is safe to do from the compiler thread? I don't think it is.

Also, any tests here? How did you find this bug?
Comment 3 Keith Miller 2018-01-19 10:09:21 PST 
I misread the code ignore this...
Comment 4 Filip Pizlo 2018-03-10 15:47:15 PST 
Yeah, if we didn’t create the allocator by the time we JIT that path, then it’s probably not hot enough to be worth optimizing that much. So, even if the GC did support creating allocators from any thread, I’m not sure doing that here would be better.