TypeProfiler and running GC collection on another thread don't play nicely with each...
authorsbarati@apple.com <sbarati@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 9 Nov 2016 22:02:20 +0000 (22:02 +0000)
committersbarati@apple.com <sbarati@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 9 Nov 2016 22:02:20 +0000 (22:02 +0000)
commit9ad27af56945ba706563e43f69987d06bb9a5230
treed3ecb081c4b33cd5a2167b50eae14a969b9a4cb2
parenta7bb1af175d93d78739e858f6a39cd7b8acc39cf
TypeProfiler and running GC collection on another thread don't play nicely with each other
https://bugs.webkit.org/show_bug.cgi?id=164441
<rdar://problem/29132174>

Reviewed by Geoffrey Garen.

JSTests:

* typeProfiler/type-profiler-gc.js: Added.
(bar):
(foo):

Source/JavaScriptCore:

This fix here is simple: we now treat the type profiler log as a GC root.
GC will make sure that we mark any values/structures that are in the log.
It's easy to reason about the correctness of this, and it also solves
the problem that we were clearing the log on the GC thread. Clearing the
log on the GC thread was a problem because when we clear the log, we may
allocate, which we're not allowed to do from the GC thread.

* heap/Heap.cpp:
(JSC::Heap::markRoots):
(JSC::Heap::visitTypeProfiler):
(JSC::Heap::collectInThread):
* heap/Heap.h:
* runtime/TypeProfilerLog.cpp:
(JSC::TypeProfilerLog::processLogEntries):
(JSC::TypeProfilerLog::visit):
* runtime/TypeProfilerLog.h:

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@208483 268f45cc-cd09-0410-ab3c-d52691b4dbfc
JSTests/ChangeLog
JSTests/typeProfiler/type-profiler-gc.js [new file with mode: 0644]
Source/JavaScriptCore/ChangeLog
Source/JavaScriptCore/heap/Heap.cpp
Source/JavaScriptCore/heap/Heap.h
Source/JavaScriptCore/runtime/TypeProfilerLog.cpp
Source/JavaScriptCore/runtime/TypeProfilerLog.h