RESOLVED FIXED 95244
ExecutableAllocator should be destructed after Heap
https://bugs.webkit.org/show_bug.cgi?id=95244
Summary ExecutableAllocator should be destructed after Heap
Yong Li
Reported 2012-08-28 14:16:55 PDT
It is said public: Heap heap; // The heap is our first data member to ensure that it's destructed after all the objects that reference it. But actually Heap can access MetaAllocator #6 WTF::MetaAllocatorHandle::~MetaAllocatorHandle #10 ~MacroAssemblerCodeRef #11 JSC::JITStubRoutine::~JITStubRoutine #13 JSC::GCAwareJITStubRoutine::~GCAwareJITStubRoutine #16 JSC::Heap::~Heap #17 JSC::JSGlobalData::~JSGlobalData This is only a problem when ENABLE(ASSEMBLER_WX_EXCLUSIVE) is true, where every ExecutableAllocator has a MetaAllocator instead of sharing the global one. But I think it is always good to make ExecutableAllocator construct before Heap and destruct after Heap as it never calls Heap, but Heap depends on ExecutableAllocator.
Attachments
the patch (1.92 KB, patch)
2012-08-29 07:25 PDT, Yong Li
webkit-ews: commit-queue-
fix the build error (3.15 KB, patch)
2012-08-29 08:46 PDT, Yong Li
ggaren: review-
Again (3.15 KB, patch)
2012-08-29 10:36 PDT, Yong Li
rwlbuis: review+
To commit (3.15 KB, patch)
2012-08-29 12:38 PDT, Yong Li
yong.li.webkit: commit-queue-
to commit (3.17 KB, patch)
2012-08-29 12:39 PDT, Yong Li
yong.li.webkit: commit-queue-
Yong Li
Comment 1 2012-08-29 07:25:43 PDT
Created attachment 161222 [details] the patch
Early Warning System Bot
Comment 2 2012-08-29 08:31:01 PDT
Early Warning System Bot
Comment 3 2012-08-29 08:39:32 PDT
Comment on attachment 161222 [details] the patch Attachment 161222 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/13695228
Yong Li
Comment 4 2012-08-29 08:46:17 PDT
Created attachment 161238 [details] fix the build error
Geoffrey Garen
Comment 5 2012-08-29 10:07:27 PDT
Comment on attachment 161238 [details] fix the build error View in context: https://bugs.webkit.org/attachment.cgi?id=161238&action=review Did you check to make sure the Executable Allocator doesn't use the heap in its constructor? > Source/JavaScriptCore/runtime/JSGlobalData.cpp:124 > + , heap(this, heapType) No need for this initializer inside the #if.
Yong Li
Comment 6 2012-08-29 10:12:58 PDT
(In reply to comment #5) > (From update of attachment 161238 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=161238&action=review > > Did you check to make sure the Executable Allocator doesn't use the heap in its constructor? Yes. ExecutableAllocator knows nothing about the heap. It doesn't even not use the JSGlobalData& argument. (checked in both ExecutableAllocator.cpp and ExecutableAllocatorFixedVMPool.cpp. It is just used to allocate memory for JIT assemblies. So logically it shouldn't rely on any other JS data. > > > Source/JavaScriptCore/runtime/JSGlobalData.cpp:124 > > + , heap(this, heapType) > > No need for this initializer inside the #if. Just for "," and ":" Would this be OK then? JSGlobalData::JSGlobalData(GlobalDataType globalDataType, ThreadStackType threadStackType, HeapType heapType) : #if ENABLE(ASSEMBLER) executableAllocator(*this), #endif heap(this, heapType) , globalDataType(globalDataType)
Geoffrey Garen
Comment 7 2012-08-29 10:26:13 PDT
> Would this be OK then? Yes.
Yong Li
Comment 8 2012-08-29 10:36:11 PDT
Rob Buis
Comment 9 2012-08-29 12:31:48 PDT
Comment on attachment 161266 [details] Again View in context: https://bugs.webkit.org/attachment.cgi?id=161266&action=review Looks good. > Source/JavaScriptCore/ChangeLog:9 > + Existing Web Worker tests can show the issue. Can you include PR?
Yong Li
Comment 10 2012-08-29 12:38:49 PDT
Created attachment 161286 [details] To commit
Yong Li
Comment 11 2012-08-29 12:39:38 PDT
Created attachment 161287 [details] to commit
Yong Li
Comment 12 2012-08-29 12:55:47 PDT
Landed @r127034.
Note You need to log in before you can comment on or make changes to this bug.