Bug 95244 - ExecutableAllocator should be destructed after Heap
Summary: ExecutableAllocator should be destructed after Heap
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-28 14:16 PDT by Yong Li
Modified: 2012-08-29 12:55 PDT (History)
3 users (show)

See Also:


Attachments
the patch (1.92 KB, patch)
2012-08-29 07:25 PDT, Yong Li
webkit-ews: commit-queue-
Details | Formatted Diff | Diff
fix the build error (3.15 KB, patch)
2012-08-29 08:46 PDT, Yong Li
ggaren: review-
Details | Formatted Diff | Diff
Again (3.15 KB, patch)
2012-08-29 10:36 PDT, Yong Li
rwlbuis: review+
Details | Formatted Diff | Diff
To commit (3.15 KB, patch)
2012-08-29 12:38 PDT, Yong Li
yong.li.webkit: commit-queue-
Details | Formatted Diff | Diff
to commit (3.17 KB, patch)
2012-08-29 12:39 PDT, Yong Li
yong.li.webkit: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yong Li 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.
Comment 1 Yong Li 2012-08-29 07:25:43 PDT
Created attachment 161222 [details]
the patch
Comment 2 Early Warning System Bot 2012-08-29 08:31:01 PDT
Comment on attachment 161222 [details]
the patch

Attachment 161222 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/13681246
Comment 3 Early Warning System Bot 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
Comment 4 Yong Li 2012-08-29 08:46:17 PDT
Created attachment 161238 [details]
fix the build error
Comment 5 Geoffrey Garen 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.
Comment 6 Yong Li 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)
Comment 7 Geoffrey Garen 2012-08-29 10:26:13 PDT
> Would this be OK then?

Yes.
Comment 8 Yong Li 2012-08-29 10:36:11 PDT
Created attachment 161266 [details]
Again
Comment 9 Rob Buis 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?
Comment 10 Yong Li 2012-08-29 12:38:49 PDT
Created attachment 161286 [details]
To commit
Comment 11 Yong Li 2012-08-29 12:39:38 PDT
Created attachment 161287 [details]
to commit
Comment 12 Yong Li 2012-08-29 12:55:47 PDT
Landed @r127034.