WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
/*
|
2020-05-07 19:49:37 +00:00
|
|
|
* Copyright (C) 2016-2020 Apple Inc. All rights reserved.
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY APPLE INC. ``AS IS'' AND ANY
|
|
|
|
* EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
|
|
|
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL APPLE INC. OR
|
|
|
|
* CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
|
|
|
|
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
|
|
|
|
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
|
|
|
|
* PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
|
|
|
|
* OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
|
|
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
2018-10-15 14:24:49 +00:00
|
|
|
#pragma once
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
|
|
|
|
#include <wtf/Box.h>
|
|
|
|
#include <wtf/Condition.h>
|
|
|
|
#include <wtf/Lock.h>
|
|
|
|
#include <wtf/ThreadSafeRefCounted.h>
|
2020-05-07 19:49:37 +00:00
|
|
|
#include <wtf/Threading.h>
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
#include <wtf/Vector.h>
|
|
|
|
|
|
|
|
namespace WTF {
|
|
|
|
|
|
|
|
// Often, we create threads that have this as their body:
|
|
|
|
//
|
|
|
|
// for (;;) {
|
|
|
|
// {
|
2021-05-22 16:49:42 +00:00
|
|
|
// Locker locker { m_lock };
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
// for (;;) {
|
|
|
|
// [1] stuff that could break, return, or fall through;
|
|
|
|
// m_condition.wait(m_lock);
|
|
|
|
// }
|
|
|
|
// }
|
|
|
|
//
|
|
|
|
// [2] do work;
|
|
|
|
// }
|
|
|
|
//
|
|
|
|
// When we do this, we don't always do a good job of managing this thread's lifetime, which may lead
|
|
|
|
// to this thread sitting around even when it is not needed.
|
|
|
|
//
|
|
|
|
// AutomaticThread is here to help you in these situations. It encapsulates a lock, a condition
|
2017-05-18 18:56:15 +00:00
|
|
|
// variable, and a thread. It will automatically shut the thread down after a timeout of inactivity.
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
// You use AutomaticThread by subclassing it, and put any state that is needed between [1] and [2]
|
|
|
|
// in the subclass.
|
|
|
|
//
|
|
|
|
// The terminology we use is:
|
|
|
|
//
|
|
|
|
// [1] PollResult AutomaticThread::poll()
|
2017-06-28 11:23:39 +00:00
|
|
|
// [2] WorkResult AutomaticThread::work()
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
//
|
|
|
|
// Note that poll() and work() may not be called on the same thread every time, since this will shut
|
|
|
|
// down the thread as necessary. This is legal since m_condition.wait(m_lock) can drop the lock, and
|
|
|
|
// so there is no reason to keep the thread around.
|
|
|
|
|
|
|
|
class AutomaticThread;
|
|
|
|
|
The GC should be in a thread
https://bugs.webkit.org/show_bug.cgi?id=163562
Reviewed by Geoffrey Garen and Andreas Kling.
Source/JavaScriptCore:
In a concurrent GC, the work of collecting happens on a separate thread. This patch
implements this, and schedules the thread the way that a concurrent GC thread would be
scheduled. But, the GC isn't actually concurrent yet because it calls stopTheWorld() before
doing anything and calls resumeTheWorld() after it's done with everything. The next step will
be to make it really concurrent by basically calling stopTheWorld()/resumeTheWorld() around
bounded snippets of work while making most of the work happen with the world running. Our GC
will probably always have stop-the-world phases because the semantics of JSC weak references
call for it.
This implements concurrent GC scheduling. This means that there is no longer a
Heap::collect() API. Instead, you can call collectAsync() which makes sure that a GC is
scheduled (it will do nothing if one is scheduled or ongoing) or you can call collectSync()
to schedule a GC and wait for it to happen. I made our debugging stuff call collectSync().
It should be a goal to never call collectSync() except for debugging or benchmark harness
hacks.
The collector thread is an AutomaticThread, so it won't linger when not in use. It works on
a ticket-based system, like you would see at the DMV. A ticket is a 64-bit integer. There are
two ticket counters: last granted and last served. When you request a collection, last
granted is incremented and its new value given to you. When a collection completes, last
served is incremented. collectSync() waits until last served catches up to what last granted
had been at the time you requested a GC. This means that if you request a sync GC in the
middle of an async GC, you will wait for that async GC to finish and then you will request
and wait for your sync GC.
The synchronization between the collector thread and the main threads is complex. The
collector thread needs to be able to ask the main thread to stop. It needs to be able to do
some post-GC clean-up, like the synchronous CodeBlock and LargeAllocation sweeps, on the main
thread. The collector needs to be able to ask the main thread to execute a cross-modifying
code fence before running any JIT code, since the GC might aid the JIT worklist and run JIT
finalization. It's possible for the GC to want the main thread to run something at the same
time that the main thread wants to wait for the GC. The main thread needs to be able to run
non-JSC stuff without causing the GC to completely stall. The main thread needs to be able
to query its own state (is there a request to stop?) and change it (running JSC versus not)
quickly, since this may happen on hot paths. This kind of intertwined system of requests,
notifications, and state changes requires a combination of lock-free algorithms and waiting.
So, this is all implemented using a Atomic<unsigned> Heap::m_worldState, which has bits to
represent things being requested by the collector and the heap access state of the mutator. I
am borrowing a lot of terms that I've seen in other VMs that I've worked on. Here's what they
mean:
- Stop the world: make sure that either the mutator is not running, or that it's not running
code that could mess with the heap.
- Heap access: the mutator is said to have heap access if it could mess with the heap.
If you stop the world and the mutator doesn't have heap access, all you're doing is making
sure that it will block when it tries to acquire heap access. This means that our GC is
already fully concurrent in cases where the GC is requested while the mutator has no heap
access. This probably won't happen, but if it did then it should just work. Usually, stopping
the world means that we state our shouldStop request with m_worldState, and a future call
to Heap::stopIfNecessary() will go to slow path and stop. The act of stopping or waiting to
acquire heap access is managed by using ParkingLot API directly on m_worldState. This works
out great because it would be very awkward to get the same functionality using locks and
condition variables, since we want stopIfNecessary/acquireAccess/requestAccess fast paths
that are single atomic instructions (load/CAS/CAS, respectively). The mutator will call these
things frequently. Currently we have Heap::stopIfNecessary() polling on every allocator slow
path, but we may want to make it even more frequent than that.
Currently only JSC API clients benefit from the heap access optimization. The DOM forces us
to assume that heap access is permanently on, since DOM manipulation doesn't always hold the
JSLock. We could still allow the GC to proceed when the runloop is idle by having the GC put
a task on the runloop that just calls stopIfNecessary().
This is perf neutral. The only behavior change that clients ought to observe is that marking
and the weak fixpoint happen on a separate thread. Marking was already parallel so it already
handled multiple threads, but now it _never_ runs on the main thread. The weak fixpoint
needed some help to be able to run on another thread - mostly because there was some code in
IndexedDB that was using thread specifics in the weak fixpoint.
* API/JSBase.cpp:
(JSSynchronousEdenCollectForDebugging):
* API/JSManagedValue.mm:
(-[JSManagedValue initWithValue:]):
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::doCollection):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
* heap/Heap.cpp:
(JSC::Heap::Thread::Thread):
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::markRoots):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::deleteUnmarkedCompiledCode):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::shouldCollectInThread):
(JSC::Heap::collectInThread):
(JSC::Heap::stopTheWorld):
(JSC::Heap::resumeTheWorld):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::acquireAccessSlow):
(JSC::Heap::releaseAccessSlow):
(JSC::Heap::handleDidJIT):
(JSC::Heap::handleNeedFinalize):
(JSC::Heap::setDidJIT):
(JSC::Heap::setNeedFinalize):
(JSC::Heap::waitWhileNeedFinalize):
(JSC::Heap::finalize):
(JSC::Heap::requestCollection):
(JSC::Heap::waitForCollection):
(JSC::Heap::didFinishCollection):
(JSC::Heap::canCollect):
(JSC::Heap::shouldCollectHeuristic):
(JSC::Heap::shouldCollect):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::collectAccordingToDeferGCProbability):
(JSC::Heap::collect): Deleted.
(JSC::Heap::collectWithoutAnySweep): Deleted.
(JSC::Heap::collectImpl): Deleted.
* heap/Heap.h:
(JSC::Heap::ReleaseAccessScope::ReleaseAccessScope):
(JSC::Heap::ReleaseAccessScope::~ReleaseAccessScope):
* heap/HeapInlines.h:
(JSC::Heap::acquireAccess):
(JSC::Heap::releaseAccess):
(JSC::Heap::stopIfNecessary):
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherConservativeRoots):
(JSC::MachineThreads::gatherFromCurrentThread): Deleted.
* heap/MachineStackMarker.h:
* jit/JITWorklist.cpp:
(JSC::JITWorklist::completeAllForVM):
* jit/JITWorklist.h:
* jsc.cpp:
(functionFullGC):
(functionEdenGC):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
(JSC::JSLock::unlock):
(JSC::JSLock::willReleaseLock):
* tools/JSDollarVMPrototype.cpp:
(JSC::JSDollarVMPrototype::edenGC):
Source/WebCore:
No new tests because existing tests cover this.
We now need to be more careful about using JSLock. This fixes some places that were not
holding it. New assertions in the GC are more likely to catch this than before.
* bindings/js/WorkerScriptController.cpp:
(WebCore::WorkerScriptController::WorkerScriptController):
Source/WTF:
This fixes some bugs and adds a few features.
* wtf/Atomics.h: The GC may do work on behalf of the JIT. If it does, the main thread needs to execute a cross-modifying code fence. This is cpuid on x86 and I believe it's isb on ARM. It would have been an isync on PPC and I think that isb is the ARM equivalent.
(WTF::arm_isb):
(WTF::crossModifyingCodeFence):
(WTF::x86_ortop):
(WTF::x86_cpuid):
* wtf/AutomaticThread.cpp: I accidentally had AutomaticThreadCondition inherit from ThreadSafeRefCounted<AutomaticThread> [sic]. This never crashed before because all of our prior AutomaticThreadConditions were immortal.
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h:
* wtf/MainThread.cpp: Need to allow initializeGCThreads() to be called separately because it's now more than just a debugging thing.
(WTF::initializeGCThreads):
Canonical link: https://commits.webkit.org/182065@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@208306 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-11-02 22:01:04 +00:00
|
|
|
class AutomaticThreadCondition : public ThreadSafeRefCounted<AutomaticThreadCondition> {
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
public:
|
2018-06-23 09:59:04 +00:00
|
|
|
static WTF_EXPORT_PRIVATE Ref<AutomaticThreadCondition> create();
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
|
|
|
|
WTF_EXPORT_PRIVATE ~AutomaticThreadCondition();
|
|
|
|
|
The collector thread should only start when the mutator doesn't have heap access
https://bugs.webkit.org/show_bug.cgi?id=167737
Reviewed by Keith Miller.
JSTests:
Add versions of splay that flash heap access, to simulate what might happen if a third-party app
was running concurrent GC. In this case, we might actually start the collector thread.
* stress/splay-flash-access-1ms.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
* stress/splay-flash-access.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
Source/JavaScriptCore:
This turns the collector thread's workflow into a state machine, so that the mutator thread can
run it directly. This reduces the amount of synchronization we do with the collector thread, and
means that most apps will never start the collector thread. The collector thread will still start
when we need to finish collecting and we don't have heap access.
In this new world, "stopping the world" means relinquishing control of collection to the mutator.
This means tracking who is conducting collection. I use the GCConductor enum to say who is
conducting. It's either GCConductor::Mutator or GCConductor::Collector. I use the term "conn" to
refer to the concept of conducting (having the conn, relinquishing the conn, taking the conn).
So, stopping the world means giving the mutator the conn. Releasing heap access means giving the
collector the conn.
This meant bringing back the conservative scan of the calling thread. It turns out that this
scan was too slow to be called on each GC increment because apparently setjmp() now does system
calls. So, I wrote our own callee save register saving for the GC. Then I had doubts about
whether or not it was correct, so I also made it so that the GC only rarely asks for the register
state. I think we still want to use my register saving code instead of setjmp because setjmp
seems to save things we don't need, and that could make us overly conservative.
It turns out that this new scheduling discipline makes the old space-time scheduler perform
better than the new stochastic space-time scheduler on systems with fewer than 4 cores. This is
because the mutator having the conn enables us to time the mutator<->collector context switches
by polling. The OS is never involved. So, we can use super precise timing. This allows the old
space-time schduler to shine like it hadn't before.
The splay results imply that this is all a good thing. On 2-core systems, this reduces pause
times by 40% and it increases throughput about 5%. On 1-core systems, this reduces pause times by
half and reduces throughput by 8%. On 4-or-more-core systems, this doesn't seem to have much
effect.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitChildren):
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::ThreadBody::ThreadBody):
(JSC::DFG::Worklist::dump):
(JSC::DFG::numberOfWorklists):
(JSC::DFG::ensureWorklistForIndex):
(JSC::DFG::existingWorklistForIndexOrNull):
(JSC::DFG::existingWorklistForIndex):
* dfg/DFGWorklist.h:
(JSC::DFG::numberOfWorklists): Deleted.
(JSC::DFG::ensureWorklistForIndex): Deleted.
(JSC::DFG::existingWorklistForIndexOrNull): Deleted.
(JSC::DFG::existingWorklistForIndex): Deleted.
* heap/CollectingScope.h: Added.
(JSC::CollectingScope::CollectingScope):
(JSC::CollectingScope::~CollectingScope):
* heap/CollectorPhase.cpp: Added.
(JSC::worldShouldBeSuspended):
(WTF::printInternal):
* heap/CollectorPhase.h: Added.
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::lastGCLength):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
(JSC::FullGCActivityCallback::lastGCLength):
* heap/GCConductor.cpp: Added.
(JSC::gcConductorShortName):
(WTF::printInternal):
* heap/GCConductor.h: Added.
* heap/GCFinalizationCallback.cpp: Added.
(JSC::GCFinalizationCallback::GCFinalizationCallback):
(JSC::GCFinalizationCallback::~GCFinalizationCallback):
* heap/GCFinalizationCallback.h: Added.
(JSC::GCFinalizationCallbackFuncAdaptor::GCFinalizationCallbackFuncAdaptor):
(JSC::createGCFinalizationCallback):
* heap/Heap.cpp:
(JSC::Heap::Thread::Thread):
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::sweepSynchronously):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::shouldCollectInCollectorThread):
(JSC::Heap::collectInCollectorThread):
(JSC::Heap::checkConn):
(JSC::Heap::runNotRunningPhase):
(JSC::Heap::runBeginPhase):
(JSC::Heap::runFixpointPhase):
(JSC::Heap::runConcurrentPhase):
(JSC::Heap::runReloopPhase):
(JSC::Heap::runEndPhase):
(JSC::Heap::changePhase):
(JSC::Heap::finishChangingPhase):
(JSC::Heap::stopThePeriphery):
(JSC::Heap::resumeThePeriphery):
(JSC::Heap::stopTheMutator):
(JSC::Heap::resumeTheMutator):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectInMutatorThread):
(JSC::Heap::waitForCollector):
(JSC::Heap::acquireAccessSlow):
(JSC::Heap::releaseAccessSlow):
(JSC::Heap::relinquishConn):
(JSC::Heap::finishRelinquishingConn):
(JSC::Heap::handleNeedFinalize):
(JSC::Heap::notifyThreadStopping):
(JSC::Heap::finalize):
(JSC::Heap::addFinalizationCallback):
(JSC::Heap::requestCollection):
(JSC::Heap::waitForCollection):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didFinishCollection):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::notifyIsSafeToCollect):
(JSC::Heap::preventCollection):
(JSC::Heap::performIncrement):
(JSC::Heap::markToFixpoint): Deleted.
(JSC::Heap::shouldCollectInThread): Deleted.
(JSC::Heap::collectInThread): Deleted.
(JSC::Heap::stopTheWorld): Deleted.
(JSC::Heap::resumeTheWorld): Deleted.
* heap/Heap.h:
(JSC::Heap::machineThreads):
(JSC::Heap::lastFullGCLength):
(JSC::Heap::lastEdenGCLength):
(JSC::Heap::increaseLastFullGCLength):
* heap/HeapInlines.h:
(JSC::Heap::mutatorIsStopped): Deleted.
* heap/HeapStatistics.cpp: Removed.
* heap/HeapStatistics.h: Removed.
* heap/HelpingGCScope.h: Removed.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::stopSweeping):
(JSC::IncrementalSweeper::willFinishSweeping): Deleted.
* heap/IncrementalSweeper.h:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::gatherConservativeRoots):
(JSC::callWithCurrentThreadState):
* heap/MachineStackMarker.h:
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateSlowCaseImpl):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::sweep):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::sweep):
* heap/MutatorState.cpp:
(WTF::printInternal):
* heap/MutatorState.h:
* heap/RegisterState.h: Added.
* heap/RunningScope.h: Added.
(JSC::RunningScope::RunningScope):
(JSC::RunningScope::~RunningScope):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::SlotVisitor):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::drainInParallelPassively):
(JSC::SlotVisitor::donateAll):
(JSC::SlotVisitor::donate):
* heap/SlotVisitor.h:
(JSC::SlotVisitor::codeName):
* heap/StochasticSpaceTimeMutatorScheduler.cpp:
(JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
(JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
(JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
* heap/SweepingScope.h: Added.
(JSC::SweepingScope::SweepingScope):
(JSC::SweepingScope::~SweepingScope):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Thread::Thread):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionFlashHeapAccess):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
* runtime/Options.cpp:
(JSC::overrideDefaults):
* runtime/Options.h:
* runtime/TestRunnerUtils.cpp:
(JSC::finalizeStatsAtEndOfTesting):
Source/WebCore:
Added new tests in JSTests.
The WebCore changes involve:
- Refactoring around new header discipline.
- Adding crazy GC APIs to window.internals to enable us to test the GC's runloop discipline.
* ForwardingHeaders/heap/GCFinalizationCallback.h: Added.
* ForwardingHeaders/heap/IncrementalSweeper.h: Added.
* ForwardingHeaders/heap/MachineStackMarker.h: Added.
* ForwardingHeaders/heap/RunningScope.h: Added.
* bindings/js/CommonVM.cpp:
* testing/Internals.cpp:
(WebCore::Internals::parserMetaData):
(WebCore::Internals::isReadableStreamDisturbed):
(WebCore::Internals::isGCRunning):
(WebCore::Internals::addGCFinalizationCallback):
(WebCore::Internals::stopSweeping):
(WebCore::Internals::startSweeping):
* testing/Internals.h:
* testing/Internals.idl:
Source/WTF:
Extend the use of AbstractLocker so that we can use more locking idioms.
* wtf/AutomaticThread.cpp:
(WTF::AutomaticThreadCondition::notifyOne):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::tryStop):
(WTF::AutomaticThread::isWaiting):
(WTF::AutomaticThread::notify):
(WTF::AutomaticThread::start):
(WTF::AutomaticThread::threadIsStopping):
* wtf/AutomaticThread.h:
* wtf/NumberOfCores.cpp:
(WTF::numberOfProcessorCores):
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::claimTask):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::hasClientWithTask):
(WTF::ParallelHelperPool::getClientWithTask):
* wtf/ParallelHelperPool.h:
Tools:
Make more tests collect continuously.
* Scripts/run-jsc-stress-tests:
Canonical link: https://commits.webkit.org/185692@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@212778 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-02-22 00:58:15 +00:00
|
|
|
WTF_EXPORT_PRIVATE void notifyOne(const AbstractLocker&);
|
|
|
|
WTF_EXPORT_PRIVATE void notifyAll(const AbstractLocker&);
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
|
2016-10-19 20:37:20 +00:00
|
|
|
// You can reuse this condition for other things, just as you would any other condition.
|
|
|
|
// However, since conflating conditions could lead to thundering herd, it's best to avoid it.
|
|
|
|
// One known-good case for one-true-condition is when the communication involves just two
|
|
|
|
// threads. In such cases, the thread doing the notifyAll() can wake up at most one thread -
|
|
|
|
// its partner.
|
2021-05-26 16:46:37 +00:00
|
|
|
WTF_EXPORT_PRIVATE void wait(Lock& lock) WTF_REQUIRES_LOCK(lock);
|
|
|
|
WTF_EXPORT_PRIVATE bool waitFor(Lock& lock, Seconds) WTF_REQUIRES_LOCK(lock);
|
2016-10-19 20:37:20 +00:00
|
|
|
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
private:
|
|
|
|
friend class AutomaticThread;
|
|
|
|
|
|
|
|
WTF_EXPORT_PRIVATE AutomaticThreadCondition();
|
|
|
|
|
The collector thread should only start when the mutator doesn't have heap access
https://bugs.webkit.org/show_bug.cgi?id=167737
Reviewed by Keith Miller.
JSTests:
Add versions of splay that flash heap access, to simulate what might happen if a third-party app
was running concurrent GC. In this case, we might actually start the collector thread.
* stress/splay-flash-access-1ms.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
* stress/splay-flash-access.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
Source/JavaScriptCore:
This turns the collector thread's workflow into a state machine, so that the mutator thread can
run it directly. This reduces the amount of synchronization we do with the collector thread, and
means that most apps will never start the collector thread. The collector thread will still start
when we need to finish collecting and we don't have heap access.
In this new world, "stopping the world" means relinquishing control of collection to the mutator.
This means tracking who is conducting collection. I use the GCConductor enum to say who is
conducting. It's either GCConductor::Mutator or GCConductor::Collector. I use the term "conn" to
refer to the concept of conducting (having the conn, relinquishing the conn, taking the conn).
So, stopping the world means giving the mutator the conn. Releasing heap access means giving the
collector the conn.
This meant bringing back the conservative scan of the calling thread. It turns out that this
scan was too slow to be called on each GC increment because apparently setjmp() now does system
calls. So, I wrote our own callee save register saving for the GC. Then I had doubts about
whether or not it was correct, so I also made it so that the GC only rarely asks for the register
state. I think we still want to use my register saving code instead of setjmp because setjmp
seems to save things we don't need, and that could make us overly conservative.
It turns out that this new scheduling discipline makes the old space-time scheduler perform
better than the new stochastic space-time scheduler on systems with fewer than 4 cores. This is
because the mutator having the conn enables us to time the mutator<->collector context switches
by polling. The OS is never involved. So, we can use super precise timing. This allows the old
space-time schduler to shine like it hadn't before.
The splay results imply that this is all a good thing. On 2-core systems, this reduces pause
times by 40% and it increases throughput about 5%. On 1-core systems, this reduces pause times by
half and reduces throughput by 8%. On 4-or-more-core systems, this doesn't seem to have much
effect.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitChildren):
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::ThreadBody::ThreadBody):
(JSC::DFG::Worklist::dump):
(JSC::DFG::numberOfWorklists):
(JSC::DFG::ensureWorklistForIndex):
(JSC::DFG::existingWorklistForIndexOrNull):
(JSC::DFG::existingWorklistForIndex):
* dfg/DFGWorklist.h:
(JSC::DFG::numberOfWorklists): Deleted.
(JSC::DFG::ensureWorklistForIndex): Deleted.
(JSC::DFG::existingWorklistForIndexOrNull): Deleted.
(JSC::DFG::existingWorklistForIndex): Deleted.
* heap/CollectingScope.h: Added.
(JSC::CollectingScope::CollectingScope):
(JSC::CollectingScope::~CollectingScope):
* heap/CollectorPhase.cpp: Added.
(JSC::worldShouldBeSuspended):
(WTF::printInternal):
* heap/CollectorPhase.h: Added.
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::lastGCLength):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
(JSC::FullGCActivityCallback::lastGCLength):
* heap/GCConductor.cpp: Added.
(JSC::gcConductorShortName):
(WTF::printInternal):
* heap/GCConductor.h: Added.
* heap/GCFinalizationCallback.cpp: Added.
(JSC::GCFinalizationCallback::GCFinalizationCallback):
(JSC::GCFinalizationCallback::~GCFinalizationCallback):
* heap/GCFinalizationCallback.h: Added.
(JSC::GCFinalizationCallbackFuncAdaptor::GCFinalizationCallbackFuncAdaptor):
(JSC::createGCFinalizationCallback):
* heap/Heap.cpp:
(JSC::Heap::Thread::Thread):
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::sweepSynchronously):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::shouldCollectInCollectorThread):
(JSC::Heap::collectInCollectorThread):
(JSC::Heap::checkConn):
(JSC::Heap::runNotRunningPhase):
(JSC::Heap::runBeginPhase):
(JSC::Heap::runFixpointPhase):
(JSC::Heap::runConcurrentPhase):
(JSC::Heap::runReloopPhase):
(JSC::Heap::runEndPhase):
(JSC::Heap::changePhase):
(JSC::Heap::finishChangingPhase):
(JSC::Heap::stopThePeriphery):
(JSC::Heap::resumeThePeriphery):
(JSC::Heap::stopTheMutator):
(JSC::Heap::resumeTheMutator):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectInMutatorThread):
(JSC::Heap::waitForCollector):
(JSC::Heap::acquireAccessSlow):
(JSC::Heap::releaseAccessSlow):
(JSC::Heap::relinquishConn):
(JSC::Heap::finishRelinquishingConn):
(JSC::Heap::handleNeedFinalize):
(JSC::Heap::notifyThreadStopping):
(JSC::Heap::finalize):
(JSC::Heap::addFinalizationCallback):
(JSC::Heap::requestCollection):
(JSC::Heap::waitForCollection):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didFinishCollection):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::notifyIsSafeToCollect):
(JSC::Heap::preventCollection):
(JSC::Heap::performIncrement):
(JSC::Heap::markToFixpoint): Deleted.
(JSC::Heap::shouldCollectInThread): Deleted.
(JSC::Heap::collectInThread): Deleted.
(JSC::Heap::stopTheWorld): Deleted.
(JSC::Heap::resumeTheWorld): Deleted.
* heap/Heap.h:
(JSC::Heap::machineThreads):
(JSC::Heap::lastFullGCLength):
(JSC::Heap::lastEdenGCLength):
(JSC::Heap::increaseLastFullGCLength):
* heap/HeapInlines.h:
(JSC::Heap::mutatorIsStopped): Deleted.
* heap/HeapStatistics.cpp: Removed.
* heap/HeapStatistics.h: Removed.
* heap/HelpingGCScope.h: Removed.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::stopSweeping):
(JSC::IncrementalSweeper::willFinishSweeping): Deleted.
* heap/IncrementalSweeper.h:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::gatherConservativeRoots):
(JSC::callWithCurrentThreadState):
* heap/MachineStackMarker.h:
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateSlowCaseImpl):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::sweep):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::sweep):
* heap/MutatorState.cpp:
(WTF::printInternal):
* heap/MutatorState.h:
* heap/RegisterState.h: Added.
* heap/RunningScope.h: Added.
(JSC::RunningScope::RunningScope):
(JSC::RunningScope::~RunningScope):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::SlotVisitor):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::drainInParallelPassively):
(JSC::SlotVisitor::donateAll):
(JSC::SlotVisitor::donate):
* heap/SlotVisitor.h:
(JSC::SlotVisitor::codeName):
* heap/StochasticSpaceTimeMutatorScheduler.cpp:
(JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
(JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
(JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
* heap/SweepingScope.h: Added.
(JSC::SweepingScope::SweepingScope):
(JSC::SweepingScope::~SweepingScope):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Thread::Thread):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionFlashHeapAccess):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
* runtime/Options.cpp:
(JSC::overrideDefaults):
* runtime/Options.h:
* runtime/TestRunnerUtils.cpp:
(JSC::finalizeStatsAtEndOfTesting):
Source/WebCore:
Added new tests in JSTests.
The WebCore changes involve:
- Refactoring around new header discipline.
- Adding crazy GC APIs to window.internals to enable us to test the GC's runloop discipline.
* ForwardingHeaders/heap/GCFinalizationCallback.h: Added.
* ForwardingHeaders/heap/IncrementalSweeper.h: Added.
* ForwardingHeaders/heap/MachineStackMarker.h: Added.
* ForwardingHeaders/heap/RunningScope.h: Added.
* bindings/js/CommonVM.cpp:
* testing/Internals.cpp:
(WebCore::Internals::parserMetaData):
(WebCore::Internals::isReadableStreamDisturbed):
(WebCore::Internals::isGCRunning):
(WebCore::Internals::addGCFinalizationCallback):
(WebCore::Internals::stopSweeping):
(WebCore::Internals::startSweeping):
* testing/Internals.h:
* testing/Internals.idl:
Source/WTF:
Extend the use of AbstractLocker so that we can use more locking idioms.
* wtf/AutomaticThread.cpp:
(WTF::AutomaticThreadCondition::notifyOne):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::tryStop):
(WTF::AutomaticThread::isWaiting):
(WTF::AutomaticThread::notify):
(WTF::AutomaticThread::start):
(WTF::AutomaticThread::threadIsStopping):
* wtf/AutomaticThread.h:
* wtf/NumberOfCores.cpp:
(WTF::numberOfProcessorCores):
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::claimTask):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::hasClientWithTask):
(WTF::ParallelHelperPool::getClientWithTask):
* wtf/ParallelHelperPool.h:
Tools:
Make more tests collect continuously.
* Scripts/run-jsc-stress-tests:
Canonical link: https://commits.webkit.org/185692@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@212778 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-02-22 00:58:15 +00:00
|
|
|
void add(const AbstractLocker&, AutomaticThread*);
|
|
|
|
void remove(const AbstractLocker&, AutomaticThread*);
|
|
|
|
bool contains(const AbstractLocker&, AutomaticThread*);
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
|
2021-05-26 16:46:37 +00:00
|
|
|
Condition m_condition;
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
Vector<AutomaticThread*> m_threads;
|
|
|
|
};
|
|
|
|
|
|
|
|
class WTF_EXPORT_PRIVATE AutomaticThread : public ThreadSafeRefCounted<AutomaticThread> {
|
|
|
|
public:
|
|
|
|
// Note that if you drop all of your references to an AutomaticThread then as soon as there is a
|
2017-05-18 18:56:15 +00:00
|
|
|
// timeout during which it doesn't get woken up, it will simply die on its own. This is a
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
// permanent kind of death where the AutomaticThread object goes away, rather than the temporary
|
|
|
|
// kind of death where AutomaticThread lives but its underlying thread dies. All you have to do
|
|
|
|
// to prevent permanent death is keep a ref to AutomaticThread. At time of writing, every user of
|
|
|
|
// AutomaticThread keeps a ref to it and does join() as part of the shutdown process, so only the
|
|
|
|
// temporary kind of automatic death happens in practice. We keep the permanent death feature
|
|
|
|
// because it leads to an easy-to-understand reference counting discipline (AutomaticThread holds
|
|
|
|
// strong ref to AutomaticThreadCondition and the underlying thread holds a strong ref to
|
|
|
|
// AutomaticThread).
|
|
|
|
virtual ~AutomaticThread();
|
|
|
|
|
The GC should be in a thread
https://bugs.webkit.org/show_bug.cgi?id=163562
Reviewed by Geoffrey Garen and Andreas Kling.
Source/JavaScriptCore:
In a concurrent GC, the work of collecting happens on a separate thread. This patch
implements this, and schedules the thread the way that a concurrent GC thread would be
scheduled. But, the GC isn't actually concurrent yet because it calls stopTheWorld() before
doing anything and calls resumeTheWorld() after it's done with everything. The next step will
be to make it really concurrent by basically calling stopTheWorld()/resumeTheWorld() around
bounded snippets of work while making most of the work happen with the world running. Our GC
will probably always have stop-the-world phases because the semantics of JSC weak references
call for it.
This implements concurrent GC scheduling. This means that there is no longer a
Heap::collect() API. Instead, you can call collectAsync() which makes sure that a GC is
scheduled (it will do nothing if one is scheduled or ongoing) or you can call collectSync()
to schedule a GC and wait for it to happen. I made our debugging stuff call collectSync().
It should be a goal to never call collectSync() except for debugging or benchmark harness
hacks.
The collector thread is an AutomaticThread, so it won't linger when not in use. It works on
a ticket-based system, like you would see at the DMV. A ticket is a 64-bit integer. There are
two ticket counters: last granted and last served. When you request a collection, last
granted is incremented and its new value given to you. When a collection completes, last
served is incremented. collectSync() waits until last served catches up to what last granted
had been at the time you requested a GC. This means that if you request a sync GC in the
middle of an async GC, you will wait for that async GC to finish and then you will request
and wait for your sync GC.
The synchronization between the collector thread and the main threads is complex. The
collector thread needs to be able to ask the main thread to stop. It needs to be able to do
some post-GC clean-up, like the synchronous CodeBlock and LargeAllocation sweeps, on the main
thread. The collector needs to be able to ask the main thread to execute a cross-modifying
code fence before running any JIT code, since the GC might aid the JIT worklist and run JIT
finalization. It's possible for the GC to want the main thread to run something at the same
time that the main thread wants to wait for the GC. The main thread needs to be able to run
non-JSC stuff without causing the GC to completely stall. The main thread needs to be able
to query its own state (is there a request to stop?) and change it (running JSC versus not)
quickly, since this may happen on hot paths. This kind of intertwined system of requests,
notifications, and state changes requires a combination of lock-free algorithms and waiting.
So, this is all implemented using a Atomic<unsigned> Heap::m_worldState, which has bits to
represent things being requested by the collector and the heap access state of the mutator. I
am borrowing a lot of terms that I've seen in other VMs that I've worked on. Here's what they
mean:
- Stop the world: make sure that either the mutator is not running, or that it's not running
code that could mess with the heap.
- Heap access: the mutator is said to have heap access if it could mess with the heap.
If you stop the world and the mutator doesn't have heap access, all you're doing is making
sure that it will block when it tries to acquire heap access. This means that our GC is
already fully concurrent in cases where the GC is requested while the mutator has no heap
access. This probably won't happen, but if it did then it should just work. Usually, stopping
the world means that we state our shouldStop request with m_worldState, and a future call
to Heap::stopIfNecessary() will go to slow path and stop. The act of stopping or waiting to
acquire heap access is managed by using ParkingLot API directly on m_worldState. This works
out great because it would be very awkward to get the same functionality using locks and
condition variables, since we want stopIfNecessary/acquireAccess/requestAccess fast paths
that are single atomic instructions (load/CAS/CAS, respectively). The mutator will call these
things frequently. Currently we have Heap::stopIfNecessary() polling on every allocator slow
path, but we may want to make it even more frequent than that.
Currently only JSC API clients benefit from the heap access optimization. The DOM forces us
to assume that heap access is permanently on, since DOM manipulation doesn't always hold the
JSLock. We could still allow the GC to proceed when the runloop is idle by having the GC put
a task on the runloop that just calls stopIfNecessary().
This is perf neutral. The only behavior change that clients ought to observe is that marking
and the weak fixpoint happen on a separate thread. Marking was already parallel so it already
handled multiple threads, but now it _never_ runs on the main thread. The weak fixpoint
needed some help to be able to run on another thread - mostly because there was some code in
IndexedDB that was using thread specifics in the weak fixpoint.
* API/JSBase.cpp:
(JSSynchronousEdenCollectForDebugging):
* API/JSManagedValue.mm:
(-[JSManagedValue initWithValue:]):
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::doCollection):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
* heap/Heap.cpp:
(JSC::Heap::Thread::Thread):
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::markRoots):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::deleteUnmarkedCompiledCode):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::shouldCollectInThread):
(JSC::Heap::collectInThread):
(JSC::Heap::stopTheWorld):
(JSC::Heap::resumeTheWorld):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::acquireAccessSlow):
(JSC::Heap::releaseAccessSlow):
(JSC::Heap::handleDidJIT):
(JSC::Heap::handleNeedFinalize):
(JSC::Heap::setDidJIT):
(JSC::Heap::setNeedFinalize):
(JSC::Heap::waitWhileNeedFinalize):
(JSC::Heap::finalize):
(JSC::Heap::requestCollection):
(JSC::Heap::waitForCollection):
(JSC::Heap::didFinishCollection):
(JSC::Heap::canCollect):
(JSC::Heap::shouldCollectHeuristic):
(JSC::Heap::shouldCollect):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::collectAccordingToDeferGCProbability):
(JSC::Heap::collect): Deleted.
(JSC::Heap::collectWithoutAnySweep): Deleted.
(JSC::Heap::collectImpl): Deleted.
* heap/Heap.h:
(JSC::Heap::ReleaseAccessScope::ReleaseAccessScope):
(JSC::Heap::ReleaseAccessScope::~ReleaseAccessScope):
* heap/HeapInlines.h:
(JSC::Heap::acquireAccess):
(JSC::Heap::releaseAccess):
(JSC::Heap::stopIfNecessary):
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherConservativeRoots):
(JSC::MachineThreads::gatherFromCurrentThread): Deleted.
* heap/MachineStackMarker.h:
* jit/JITWorklist.cpp:
(JSC::JITWorklist::completeAllForVM):
* jit/JITWorklist.h:
* jsc.cpp:
(functionFullGC):
(functionEdenGC):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
(JSC::JSLock::unlock):
(JSC::JSLock::willReleaseLock):
* tools/JSDollarVMPrototype.cpp:
(JSC::JSDollarVMPrototype::edenGC):
Source/WebCore:
No new tests because existing tests cover this.
We now need to be more careful about using JSLock. This fixes some places that were not
holding it. New assertions in the GC are more likely to catch this than before.
* bindings/js/WorkerScriptController.cpp:
(WebCore::WorkerScriptController::WorkerScriptController):
Source/WTF:
This fixes some bugs and adds a few features.
* wtf/Atomics.h: The GC may do work on behalf of the JIT. If it does, the main thread needs to execute a cross-modifying code fence. This is cpuid on x86 and I believe it's isb on ARM. It would have been an isync on PPC and I think that isb is the ARM equivalent.
(WTF::arm_isb):
(WTF::crossModifyingCodeFence):
(WTF::x86_ortop):
(WTF::x86_cpuid):
* wtf/AutomaticThread.cpp: I accidentally had AutomaticThreadCondition inherit from ThreadSafeRefCounted<AutomaticThread> [sic]. This never crashed before because all of our prior AutomaticThreadConditions were immortal.
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h:
* wtf/MainThread.cpp: Need to allow initializeGCThreads() to be called separately because it's now more than just a debugging thing.
(WTF::initializeGCThreads):
Canonical link: https://commits.webkit.org/182065@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@208306 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-11-02 22:01:04 +00:00
|
|
|
// Sometimes it's possible to optimize for the case that there is no underlying thread.
|
The collector thread should only start when the mutator doesn't have heap access
https://bugs.webkit.org/show_bug.cgi?id=167737
Reviewed by Keith Miller.
JSTests:
Add versions of splay that flash heap access, to simulate what might happen if a third-party app
was running concurrent GC. In this case, we might actually start the collector thread.
* stress/splay-flash-access-1ms.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
* stress/splay-flash-access.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
Source/JavaScriptCore:
This turns the collector thread's workflow into a state machine, so that the mutator thread can
run it directly. This reduces the amount of synchronization we do with the collector thread, and
means that most apps will never start the collector thread. The collector thread will still start
when we need to finish collecting and we don't have heap access.
In this new world, "stopping the world" means relinquishing control of collection to the mutator.
This means tracking who is conducting collection. I use the GCConductor enum to say who is
conducting. It's either GCConductor::Mutator or GCConductor::Collector. I use the term "conn" to
refer to the concept of conducting (having the conn, relinquishing the conn, taking the conn).
So, stopping the world means giving the mutator the conn. Releasing heap access means giving the
collector the conn.
This meant bringing back the conservative scan of the calling thread. It turns out that this
scan was too slow to be called on each GC increment because apparently setjmp() now does system
calls. So, I wrote our own callee save register saving for the GC. Then I had doubts about
whether or not it was correct, so I also made it so that the GC only rarely asks for the register
state. I think we still want to use my register saving code instead of setjmp because setjmp
seems to save things we don't need, and that could make us overly conservative.
It turns out that this new scheduling discipline makes the old space-time scheduler perform
better than the new stochastic space-time scheduler on systems with fewer than 4 cores. This is
because the mutator having the conn enables us to time the mutator<->collector context switches
by polling. The OS is never involved. So, we can use super precise timing. This allows the old
space-time schduler to shine like it hadn't before.
The splay results imply that this is all a good thing. On 2-core systems, this reduces pause
times by 40% and it increases throughput about 5%. On 1-core systems, this reduces pause times by
half and reduces throughput by 8%. On 4-or-more-core systems, this doesn't seem to have much
effect.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitChildren):
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::ThreadBody::ThreadBody):
(JSC::DFG::Worklist::dump):
(JSC::DFG::numberOfWorklists):
(JSC::DFG::ensureWorklistForIndex):
(JSC::DFG::existingWorklistForIndexOrNull):
(JSC::DFG::existingWorklistForIndex):
* dfg/DFGWorklist.h:
(JSC::DFG::numberOfWorklists): Deleted.
(JSC::DFG::ensureWorklistForIndex): Deleted.
(JSC::DFG::existingWorklistForIndexOrNull): Deleted.
(JSC::DFG::existingWorklistForIndex): Deleted.
* heap/CollectingScope.h: Added.
(JSC::CollectingScope::CollectingScope):
(JSC::CollectingScope::~CollectingScope):
* heap/CollectorPhase.cpp: Added.
(JSC::worldShouldBeSuspended):
(WTF::printInternal):
* heap/CollectorPhase.h: Added.
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::lastGCLength):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
(JSC::FullGCActivityCallback::lastGCLength):
* heap/GCConductor.cpp: Added.
(JSC::gcConductorShortName):
(WTF::printInternal):
* heap/GCConductor.h: Added.
* heap/GCFinalizationCallback.cpp: Added.
(JSC::GCFinalizationCallback::GCFinalizationCallback):
(JSC::GCFinalizationCallback::~GCFinalizationCallback):
* heap/GCFinalizationCallback.h: Added.
(JSC::GCFinalizationCallbackFuncAdaptor::GCFinalizationCallbackFuncAdaptor):
(JSC::createGCFinalizationCallback):
* heap/Heap.cpp:
(JSC::Heap::Thread::Thread):
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::sweepSynchronously):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::shouldCollectInCollectorThread):
(JSC::Heap::collectInCollectorThread):
(JSC::Heap::checkConn):
(JSC::Heap::runNotRunningPhase):
(JSC::Heap::runBeginPhase):
(JSC::Heap::runFixpointPhase):
(JSC::Heap::runConcurrentPhase):
(JSC::Heap::runReloopPhase):
(JSC::Heap::runEndPhase):
(JSC::Heap::changePhase):
(JSC::Heap::finishChangingPhase):
(JSC::Heap::stopThePeriphery):
(JSC::Heap::resumeThePeriphery):
(JSC::Heap::stopTheMutator):
(JSC::Heap::resumeTheMutator):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectInMutatorThread):
(JSC::Heap::waitForCollector):
(JSC::Heap::acquireAccessSlow):
(JSC::Heap::releaseAccessSlow):
(JSC::Heap::relinquishConn):
(JSC::Heap::finishRelinquishingConn):
(JSC::Heap::handleNeedFinalize):
(JSC::Heap::notifyThreadStopping):
(JSC::Heap::finalize):
(JSC::Heap::addFinalizationCallback):
(JSC::Heap::requestCollection):
(JSC::Heap::waitForCollection):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didFinishCollection):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::notifyIsSafeToCollect):
(JSC::Heap::preventCollection):
(JSC::Heap::performIncrement):
(JSC::Heap::markToFixpoint): Deleted.
(JSC::Heap::shouldCollectInThread): Deleted.
(JSC::Heap::collectInThread): Deleted.
(JSC::Heap::stopTheWorld): Deleted.
(JSC::Heap::resumeTheWorld): Deleted.
* heap/Heap.h:
(JSC::Heap::machineThreads):
(JSC::Heap::lastFullGCLength):
(JSC::Heap::lastEdenGCLength):
(JSC::Heap::increaseLastFullGCLength):
* heap/HeapInlines.h:
(JSC::Heap::mutatorIsStopped): Deleted.
* heap/HeapStatistics.cpp: Removed.
* heap/HeapStatistics.h: Removed.
* heap/HelpingGCScope.h: Removed.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::stopSweeping):
(JSC::IncrementalSweeper::willFinishSweeping): Deleted.
* heap/IncrementalSweeper.h:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::gatherConservativeRoots):
(JSC::callWithCurrentThreadState):
* heap/MachineStackMarker.h:
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateSlowCaseImpl):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::sweep):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::sweep):
* heap/MutatorState.cpp:
(WTF::printInternal):
* heap/MutatorState.h:
* heap/RegisterState.h: Added.
* heap/RunningScope.h: Added.
(JSC::RunningScope::RunningScope):
(JSC::RunningScope::~RunningScope):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::SlotVisitor):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::drainInParallelPassively):
(JSC::SlotVisitor::donateAll):
(JSC::SlotVisitor::donate):
* heap/SlotVisitor.h:
(JSC::SlotVisitor::codeName):
* heap/StochasticSpaceTimeMutatorScheduler.cpp:
(JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
(JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
(JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
* heap/SweepingScope.h: Added.
(JSC::SweepingScope::SweepingScope):
(JSC::SweepingScope::~SweepingScope):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Thread::Thread):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionFlashHeapAccess):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
* runtime/Options.cpp:
(JSC::overrideDefaults):
* runtime/Options.h:
* runtime/TestRunnerUtils.cpp:
(JSC::finalizeStatsAtEndOfTesting):
Source/WebCore:
Added new tests in JSTests.
The WebCore changes involve:
- Refactoring around new header discipline.
- Adding crazy GC APIs to window.internals to enable us to test the GC's runloop discipline.
* ForwardingHeaders/heap/GCFinalizationCallback.h: Added.
* ForwardingHeaders/heap/IncrementalSweeper.h: Added.
* ForwardingHeaders/heap/MachineStackMarker.h: Added.
* ForwardingHeaders/heap/RunningScope.h: Added.
* bindings/js/CommonVM.cpp:
* testing/Internals.cpp:
(WebCore::Internals::parserMetaData):
(WebCore::Internals::isReadableStreamDisturbed):
(WebCore::Internals::isGCRunning):
(WebCore::Internals::addGCFinalizationCallback):
(WebCore::Internals::stopSweeping):
(WebCore::Internals::startSweeping):
* testing/Internals.h:
* testing/Internals.idl:
Source/WTF:
Extend the use of AbstractLocker so that we can use more locking idioms.
* wtf/AutomaticThread.cpp:
(WTF::AutomaticThreadCondition::notifyOne):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::tryStop):
(WTF::AutomaticThread::isWaiting):
(WTF::AutomaticThread::notify):
(WTF::AutomaticThread::start):
(WTF::AutomaticThread::threadIsStopping):
* wtf/AutomaticThread.h:
* wtf/NumberOfCores.cpp:
(WTF::numberOfProcessorCores):
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::claimTask):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::hasClientWithTask):
(WTF::ParallelHelperPool::getClientWithTask):
* wtf/ParallelHelperPool.h:
Tools:
Make more tests collect continuously.
* Scripts/run-jsc-stress-tests:
Canonical link: https://commits.webkit.org/185692@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@212778 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-02-22 00:58:15 +00:00
|
|
|
bool hasUnderlyingThread(const AbstractLocker&) const { return m_hasUnderlyingThread; }
|
The GC should be in a thread
https://bugs.webkit.org/show_bug.cgi?id=163562
Reviewed by Geoffrey Garen and Andreas Kling.
Source/JavaScriptCore:
In a concurrent GC, the work of collecting happens on a separate thread. This patch
implements this, and schedules the thread the way that a concurrent GC thread would be
scheduled. But, the GC isn't actually concurrent yet because it calls stopTheWorld() before
doing anything and calls resumeTheWorld() after it's done with everything. The next step will
be to make it really concurrent by basically calling stopTheWorld()/resumeTheWorld() around
bounded snippets of work while making most of the work happen with the world running. Our GC
will probably always have stop-the-world phases because the semantics of JSC weak references
call for it.
This implements concurrent GC scheduling. This means that there is no longer a
Heap::collect() API. Instead, you can call collectAsync() which makes sure that a GC is
scheduled (it will do nothing if one is scheduled or ongoing) or you can call collectSync()
to schedule a GC and wait for it to happen. I made our debugging stuff call collectSync().
It should be a goal to never call collectSync() except for debugging or benchmark harness
hacks.
The collector thread is an AutomaticThread, so it won't linger when not in use. It works on
a ticket-based system, like you would see at the DMV. A ticket is a 64-bit integer. There are
two ticket counters: last granted and last served. When you request a collection, last
granted is incremented and its new value given to you. When a collection completes, last
served is incremented. collectSync() waits until last served catches up to what last granted
had been at the time you requested a GC. This means that if you request a sync GC in the
middle of an async GC, you will wait for that async GC to finish and then you will request
and wait for your sync GC.
The synchronization between the collector thread and the main threads is complex. The
collector thread needs to be able to ask the main thread to stop. It needs to be able to do
some post-GC clean-up, like the synchronous CodeBlock and LargeAllocation sweeps, on the main
thread. The collector needs to be able to ask the main thread to execute a cross-modifying
code fence before running any JIT code, since the GC might aid the JIT worklist and run JIT
finalization. It's possible for the GC to want the main thread to run something at the same
time that the main thread wants to wait for the GC. The main thread needs to be able to run
non-JSC stuff without causing the GC to completely stall. The main thread needs to be able
to query its own state (is there a request to stop?) and change it (running JSC versus not)
quickly, since this may happen on hot paths. This kind of intertwined system of requests,
notifications, and state changes requires a combination of lock-free algorithms and waiting.
So, this is all implemented using a Atomic<unsigned> Heap::m_worldState, which has bits to
represent things being requested by the collector and the heap access state of the mutator. I
am borrowing a lot of terms that I've seen in other VMs that I've worked on. Here's what they
mean:
- Stop the world: make sure that either the mutator is not running, or that it's not running
code that could mess with the heap.
- Heap access: the mutator is said to have heap access if it could mess with the heap.
If you stop the world and the mutator doesn't have heap access, all you're doing is making
sure that it will block when it tries to acquire heap access. This means that our GC is
already fully concurrent in cases where the GC is requested while the mutator has no heap
access. This probably won't happen, but if it did then it should just work. Usually, stopping
the world means that we state our shouldStop request with m_worldState, and a future call
to Heap::stopIfNecessary() will go to slow path and stop. The act of stopping or waiting to
acquire heap access is managed by using ParkingLot API directly on m_worldState. This works
out great because it would be very awkward to get the same functionality using locks and
condition variables, since we want stopIfNecessary/acquireAccess/requestAccess fast paths
that are single atomic instructions (load/CAS/CAS, respectively). The mutator will call these
things frequently. Currently we have Heap::stopIfNecessary() polling on every allocator slow
path, but we may want to make it even more frequent than that.
Currently only JSC API clients benefit from the heap access optimization. The DOM forces us
to assume that heap access is permanently on, since DOM manipulation doesn't always hold the
JSLock. We could still allow the GC to proceed when the runloop is idle by having the GC put
a task on the runloop that just calls stopIfNecessary().
This is perf neutral. The only behavior change that clients ought to observe is that marking
and the weak fixpoint happen on a separate thread. Marking was already parallel so it already
handled multiple threads, but now it _never_ runs on the main thread. The weak fixpoint
needed some help to be able to run on another thread - mostly because there was some code in
IndexedDB that was using thread specifics in the weak fixpoint.
* API/JSBase.cpp:
(JSSynchronousEdenCollectForDebugging):
* API/JSManagedValue.mm:
(-[JSManagedValue initWithValue:]):
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::doCollection):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
* heap/Heap.cpp:
(JSC::Heap::Thread::Thread):
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::markRoots):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::deleteUnmarkedCompiledCode):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::shouldCollectInThread):
(JSC::Heap::collectInThread):
(JSC::Heap::stopTheWorld):
(JSC::Heap::resumeTheWorld):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::acquireAccessSlow):
(JSC::Heap::releaseAccessSlow):
(JSC::Heap::handleDidJIT):
(JSC::Heap::handleNeedFinalize):
(JSC::Heap::setDidJIT):
(JSC::Heap::setNeedFinalize):
(JSC::Heap::waitWhileNeedFinalize):
(JSC::Heap::finalize):
(JSC::Heap::requestCollection):
(JSC::Heap::waitForCollection):
(JSC::Heap::didFinishCollection):
(JSC::Heap::canCollect):
(JSC::Heap::shouldCollectHeuristic):
(JSC::Heap::shouldCollect):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::collectAccordingToDeferGCProbability):
(JSC::Heap::collect): Deleted.
(JSC::Heap::collectWithoutAnySweep): Deleted.
(JSC::Heap::collectImpl): Deleted.
* heap/Heap.h:
(JSC::Heap::ReleaseAccessScope::ReleaseAccessScope):
(JSC::Heap::ReleaseAccessScope::~ReleaseAccessScope):
* heap/HeapInlines.h:
(JSC::Heap::acquireAccess):
(JSC::Heap::releaseAccess):
(JSC::Heap::stopIfNecessary):
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherConservativeRoots):
(JSC::MachineThreads::gatherFromCurrentThread): Deleted.
* heap/MachineStackMarker.h:
* jit/JITWorklist.cpp:
(JSC::JITWorklist::completeAllForVM):
* jit/JITWorklist.h:
* jsc.cpp:
(functionFullGC):
(functionEdenGC):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
(JSC::JSLock::unlock):
(JSC::JSLock::willReleaseLock):
* tools/JSDollarVMPrototype.cpp:
(JSC::JSDollarVMPrototype::edenGC):
Source/WebCore:
No new tests because existing tests cover this.
We now need to be more careful about using JSLock. This fixes some places that were not
holding it. New assertions in the GC are more likely to catch this than before.
* bindings/js/WorkerScriptController.cpp:
(WebCore::WorkerScriptController::WorkerScriptController):
Source/WTF:
This fixes some bugs and adds a few features.
* wtf/Atomics.h: The GC may do work on behalf of the JIT. If it does, the main thread needs to execute a cross-modifying code fence. This is cpuid on x86 and I believe it's isb on ARM. It would have been an isync on PPC and I think that isb is the ARM equivalent.
(WTF::arm_isb):
(WTF::crossModifyingCodeFence):
(WTF::x86_ortop):
(WTF::x86_cpuid):
* wtf/AutomaticThread.cpp: I accidentally had AutomaticThreadCondition inherit from ThreadSafeRefCounted<AutomaticThread> [sic]. This never crashed before because all of our prior AutomaticThreadConditions were immortal.
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h:
* wtf/MainThread.cpp: Need to allow initializeGCThreads() to be called separately because it's now more than just a debugging thing.
(WTF::initializeGCThreads):
Canonical link: https://commits.webkit.org/182065@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@208306 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-11-02 22:01:04 +00:00
|
|
|
|
|
|
|
// This attempts to quickly stop the thread. This will succeed if the thread happens to not be
|
|
|
|
// running. Returns true if the thread has been stopped. A good idiom for stopping your automatic
|
|
|
|
// thread is to first try this, and if that doesn't work, to tell the thread using your own
|
|
|
|
// mechanism (set some flag and then notify the condition).
|
The collector thread should only start when the mutator doesn't have heap access
https://bugs.webkit.org/show_bug.cgi?id=167737
Reviewed by Keith Miller.
JSTests:
Add versions of splay that flash heap access, to simulate what might happen if a third-party app
was running concurrent GC. In this case, we might actually start the collector thread.
* stress/splay-flash-access-1ms.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
* stress/splay-flash-access.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
Source/JavaScriptCore:
This turns the collector thread's workflow into a state machine, so that the mutator thread can
run it directly. This reduces the amount of synchronization we do with the collector thread, and
means that most apps will never start the collector thread. The collector thread will still start
when we need to finish collecting and we don't have heap access.
In this new world, "stopping the world" means relinquishing control of collection to the mutator.
This means tracking who is conducting collection. I use the GCConductor enum to say who is
conducting. It's either GCConductor::Mutator or GCConductor::Collector. I use the term "conn" to
refer to the concept of conducting (having the conn, relinquishing the conn, taking the conn).
So, stopping the world means giving the mutator the conn. Releasing heap access means giving the
collector the conn.
This meant bringing back the conservative scan of the calling thread. It turns out that this
scan was too slow to be called on each GC increment because apparently setjmp() now does system
calls. So, I wrote our own callee save register saving for the GC. Then I had doubts about
whether or not it was correct, so I also made it so that the GC only rarely asks for the register
state. I think we still want to use my register saving code instead of setjmp because setjmp
seems to save things we don't need, and that could make us overly conservative.
It turns out that this new scheduling discipline makes the old space-time scheduler perform
better than the new stochastic space-time scheduler on systems with fewer than 4 cores. This is
because the mutator having the conn enables us to time the mutator<->collector context switches
by polling. The OS is never involved. So, we can use super precise timing. This allows the old
space-time schduler to shine like it hadn't before.
The splay results imply that this is all a good thing. On 2-core systems, this reduces pause
times by 40% and it increases throughput about 5%. On 1-core systems, this reduces pause times by
half and reduces throughput by 8%. On 4-or-more-core systems, this doesn't seem to have much
effect.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitChildren):
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::ThreadBody::ThreadBody):
(JSC::DFG::Worklist::dump):
(JSC::DFG::numberOfWorklists):
(JSC::DFG::ensureWorklistForIndex):
(JSC::DFG::existingWorklistForIndexOrNull):
(JSC::DFG::existingWorklistForIndex):
* dfg/DFGWorklist.h:
(JSC::DFG::numberOfWorklists): Deleted.
(JSC::DFG::ensureWorklistForIndex): Deleted.
(JSC::DFG::existingWorklistForIndexOrNull): Deleted.
(JSC::DFG::existingWorklistForIndex): Deleted.
* heap/CollectingScope.h: Added.
(JSC::CollectingScope::CollectingScope):
(JSC::CollectingScope::~CollectingScope):
* heap/CollectorPhase.cpp: Added.
(JSC::worldShouldBeSuspended):
(WTF::printInternal):
* heap/CollectorPhase.h: Added.
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::lastGCLength):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
(JSC::FullGCActivityCallback::lastGCLength):
* heap/GCConductor.cpp: Added.
(JSC::gcConductorShortName):
(WTF::printInternal):
* heap/GCConductor.h: Added.
* heap/GCFinalizationCallback.cpp: Added.
(JSC::GCFinalizationCallback::GCFinalizationCallback):
(JSC::GCFinalizationCallback::~GCFinalizationCallback):
* heap/GCFinalizationCallback.h: Added.
(JSC::GCFinalizationCallbackFuncAdaptor::GCFinalizationCallbackFuncAdaptor):
(JSC::createGCFinalizationCallback):
* heap/Heap.cpp:
(JSC::Heap::Thread::Thread):
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::sweepSynchronously):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::shouldCollectInCollectorThread):
(JSC::Heap::collectInCollectorThread):
(JSC::Heap::checkConn):
(JSC::Heap::runNotRunningPhase):
(JSC::Heap::runBeginPhase):
(JSC::Heap::runFixpointPhase):
(JSC::Heap::runConcurrentPhase):
(JSC::Heap::runReloopPhase):
(JSC::Heap::runEndPhase):
(JSC::Heap::changePhase):
(JSC::Heap::finishChangingPhase):
(JSC::Heap::stopThePeriphery):
(JSC::Heap::resumeThePeriphery):
(JSC::Heap::stopTheMutator):
(JSC::Heap::resumeTheMutator):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectInMutatorThread):
(JSC::Heap::waitForCollector):
(JSC::Heap::acquireAccessSlow):
(JSC::Heap::releaseAccessSlow):
(JSC::Heap::relinquishConn):
(JSC::Heap::finishRelinquishingConn):
(JSC::Heap::handleNeedFinalize):
(JSC::Heap::notifyThreadStopping):
(JSC::Heap::finalize):
(JSC::Heap::addFinalizationCallback):
(JSC::Heap::requestCollection):
(JSC::Heap::waitForCollection):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didFinishCollection):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::notifyIsSafeToCollect):
(JSC::Heap::preventCollection):
(JSC::Heap::performIncrement):
(JSC::Heap::markToFixpoint): Deleted.
(JSC::Heap::shouldCollectInThread): Deleted.
(JSC::Heap::collectInThread): Deleted.
(JSC::Heap::stopTheWorld): Deleted.
(JSC::Heap::resumeTheWorld): Deleted.
* heap/Heap.h:
(JSC::Heap::machineThreads):
(JSC::Heap::lastFullGCLength):
(JSC::Heap::lastEdenGCLength):
(JSC::Heap::increaseLastFullGCLength):
* heap/HeapInlines.h:
(JSC::Heap::mutatorIsStopped): Deleted.
* heap/HeapStatistics.cpp: Removed.
* heap/HeapStatistics.h: Removed.
* heap/HelpingGCScope.h: Removed.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::stopSweeping):
(JSC::IncrementalSweeper::willFinishSweeping): Deleted.
* heap/IncrementalSweeper.h:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::gatherConservativeRoots):
(JSC::callWithCurrentThreadState):
* heap/MachineStackMarker.h:
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateSlowCaseImpl):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::sweep):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::sweep):
* heap/MutatorState.cpp:
(WTF::printInternal):
* heap/MutatorState.h:
* heap/RegisterState.h: Added.
* heap/RunningScope.h: Added.
(JSC::RunningScope::RunningScope):
(JSC::RunningScope::~RunningScope):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::SlotVisitor):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::drainInParallelPassively):
(JSC::SlotVisitor::donateAll):
(JSC::SlotVisitor::donate):
* heap/SlotVisitor.h:
(JSC::SlotVisitor::codeName):
* heap/StochasticSpaceTimeMutatorScheduler.cpp:
(JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
(JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
(JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
* heap/SweepingScope.h: Added.
(JSC::SweepingScope::SweepingScope):
(JSC::SweepingScope::~SweepingScope):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Thread::Thread):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionFlashHeapAccess):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
* runtime/Options.cpp:
(JSC::overrideDefaults):
* runtime/Options.h:
* runtime/TestRunnerUtils.cpp:
(JSC::finalizeStatsAtEndOfTesting):
Source/WebCore:
Added new tests in JSTests.
The WebCore changes involve:
- Refactoring around new header discipline.
- Adding crazy GC APIs to window.internals to enable us to test the GC's runloop discipline.
* ForwardingHeaders/heap/GCFinalizationCallback.h: Added.
* ForwardingHeaders/heap/IncrementalSweeper.h: Added.
* ForwardingHeaders/heap/MachineStackMarker.h: Added.
* ForwardingHeaders/heap/RunningScope.h: Added.
* bindings/js/CommonVM.cpp:
* testing/Internals.cpp:
(WebCore::Internals::parserMetaData):
(WebCore::Internals::isReadableStreamDisturbed):
(WebCore::Internals::isGCRunning):
(WebCore::Internals::addGCFinalizationCallback):
(WebCore::Internals::stopSweeping):
(WebCore::Internals::startSweeping):
* testing/Internals.h:
* testing/Internals.idl:
Source/WTF:
Extend the use of AbstractLocker so that we can use more locking idioms.
* wtf/AutomaticThread.cpp:
(WTF::AutomaticThreadCondition::notifyOne):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::tryStop):
(WTF::AutomaticThread::isWaiting):
(WTF::AutomaticThread::notify):
(WTF::AutomaticThread::start):
(WTF::AutomaticThread::threadIsStopping):
* wtf/AutomaticThread.h:
* wtf/NumberOfCores.cpp:
(WTF::numberOfProcessorCores):
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::claimTask):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::hasClientWithTask):
(WTF::ParallelHelperPool::getClientWithTask):
* wtf/ParallelHelperPool.h:
Tools:
Make more tests collect continuously.
* Scripts/run-jsc-stress-tests:
Canonical link: https://commits.webkit.org/185692@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@212778 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-02-22 00:58:15 +00:00
|
|
|
bool tryStop(const AbstractLocker&);
|
2016-12-16 22:26:09 +00:00
|
|
|
|
The collector thread should only start when the mutator doesn't have heap access
https://bugs.webkit.org/show_bug.cgi?id=167737
Reviewed by Keith Miller.
JSTests:
Add versions of splay that flash heap access, to simulate what might happen if a third-party app
was running concurrent GC. In this case, we might actually start the collector thread.
* stress/splay-flash-access-1ms.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
* stress/splay-flash-access.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
Source/JavaScriptCore:
This turns the collector thread's workflow into a state machine, so that the mutator thread can
run it directly. This reduces the amount of synchronization we do with the collector thread, and
means that most apps will never start the collector thread. The collector thread will still start
when we need to finish collecting and we don't have heap access.
In this new world, "stopping the world" means relinquishing control of collection to the mutator.
This means tracking who is conducting collection. I use the GCConductor enum to say who is
conducting. It's either GCConductor::Mutator or GCConductor::Collector. I use the term "conn" to
refer to the concept of conducting (having the conn, relinquishing the conn, taking the conn).
So, stopping the world means giving the mutator the conn. Releasing heap access means giving the
collector the conn.
This meant bringing back the conservative scan of the calling thread. It turns out that this
scan was too slow to be called on each GC increment because apparently setjmp() now does system
calls. So, I wrote our own callee save register saving for the GC. Then I had doubts about
whether or not it was correct, so I also made it so that the GC only rarely asks for the register
state. I think we still want to use my register saving code instead of setjmp because setjmp
seems to save things we don't need, and that could make us overly conservative.
It turns out that this new scheduling discipline makes the old space-time scheduler perform
better than the new stochastic space-time scheduler on systems with fewer than 4 cores. This is
because the mutator having the conn enables us to time the mutator<->collector context switches
by polling. The OS is never involved. So, we can use super precise timing. This allows the old
space-time schduler to shine like it hadn't before.
The splay results imply that this is all a good thing. On 2-core systems, this reduces pause
times by 40% and it increases throughput about 5%. On 1-core systems, this reduces pause times by
half and reduces throughput by 8%. On 4-or-more-core systems, this doesn't seem to have much
effect.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitChildren):
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::ThreadBody::ThreadBody):
(JSC::DFG::Worklist::dump):
(JSC::DFG::numberOfWorklists):
(JSC::DFG::ensureWorklistForIndex):
(JSC::DFG::existingWorklistForIndexOrNull):
(JSC::DFG::existingWorklistForIndex):
* dfg/DFGWorklist.h:
(JSC::DFG::numberOfWorklists): Deleted.
(JSC::DFG::ensureWorklistForIndex): Deleted.
(JSC::DFG::existingWorklistForIndexOrNull): Deleted.
(JSC::DFG::existingWorklistForIndex): Deleted.
* heap/CollectingScope.h: Added.
(JSC::CollectingScope::CollectingScope):
(JSC::CollectingScope::~CollectingScope):
* heap/CollectorPhase.cpp: Added.
(JSC::worldShouldBeSuspended):
(WTF::printInternal):
* heap/CollectorPhase.h: Added.
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::lastGCLength):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
(JSC::FullGCActivityCallback::lastGCLength):
* heap/GCConductor.cpp: Added.
(JSC::gcConductorShortName):
(WTF::printInternal):
* heap/GCConductor.h: Added.
* heap/GCFinalizationCallback.cpp: Added.
(JSC::GCFinalizationCallback::GCFinalizationCallback):
(JSC::GCFinalizationCallback::~GCFinalizationCallback):
* heap/GCFinalizationCallback.h: Added.
(JSC::GCFinalizationCallbackFuncAdaptor::GCFinalizationCallbackFuncAdaptor):
(JSC::createGCFinalizationCallback):
* heap/Heap.cpp:
(JSC::Heap::Thread::Thread):
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::sweepSynchronously):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::shouldCollectInCollectorThread):
(JSC::Heap::collectInCollectorThread):
(JSC::Heap::checkConn):
(JSC::Heap::runNotRunningPhase):
(JSC::Heap::runBeginPhase):
(JSC::Heap::runFixpointPhase):
(JSC::Heap::runConcurrentPhase):
(JSC::Heap::runReloopPhase):
(JSC::Heap::runEndPhase):
(JSC::Heap::changePhase):
(JSC::Heap::finishChangingPhase):
(JSC::Heap::stopThePeriphery):
(JSC::Heap::resumeThePeriphery):
(JSC::Heap::stopTheMutator):
(JSC::Heap::resumeTheMutator):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectInMutatorThread):
(JSC::Heap::waitForCollector):
(JSC::Heap::acquireAccessSlow):
(JSC::Heap::releaseAccessSlow):
(JSC::Heap::relinquishConn):
(JSC::Heap::finishRelinquishingConn):
(JSC::Heap::handleNeedFinalize):
(JSC::Heap::notifyThreadStopping):
(JSC::Heap::finalize):
(JSC::Heap::addFinalizationCallback):
(JSC::Heap::requestCollection):
(JSC::Heap::waitForCollection):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didFinishCollection):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::notifyIsSafeToCollect):
(JSC::Heap::preventCollection):
(JSC::Heap::performIncrement):
(JSC::Heap::markToFixpoint): Deleted.
(JSC::Heap::shouldCollectInThread): Deleted.
(JSC::Heap::collectInThread): Deleted.
(JSC::Heap::stopTheWorld): Deleted.
(JSC::Heap::resumeTheWorld): Deleted.
* heap/Heap.h:
(JSC::Heap::machineThreads):
(JSC::Heap::lastFullGCLength):
(JSC::Heap::lastEdenGCLength):
(JSC::Heap::increaseLastFullGCLength):
* heap/HeapInlines.h:
(JSC::Heap::mutatorIsStopped): Deleted.
* heap/HeapStatistics.cpp: Removed.
* heap/HeapStatistics.h: Removed.
* heap/HelpingGCScope.h: Removed.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::stopSweeping):
(JSC::IncrementalSweeper::willFinishSweeping): Deleted.
* heap/IncrementalSweeper.h:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::gatherConservativeRoots):
(JSC::callWithCurrentThreadState):
* heap/MachineStackMarker.h:
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateSlowCaseImpl):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::sweep):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::sweep):
* heap/MutatorState.cpp:
(WTF::printInternal):
* heap/MutatorState.h:
* heap/RegisterState.h: Added.
* heap/RunningScope.h: Added.
(JSC::RunningScope::RunningScope):
(JSC::RunningScope::~RunningScope):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::SlotVisitor):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::drainInParallelPassively):
(JSC::SlotVisitor::donateAll):
(JSC::SlotVisitor::donate):
* heap/SlotVisitor.h:
(JSC::SlotVisitor::codeName):
* heap/StochasticSpaceTimeMutatorScheduler.cpp:
(JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
(JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
(JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
* heap/SweepingScope.h: Added.
(JSC::SweepingScope::SweepingScope):
(JSC::SweepingScope::~SweepingScope):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Thread::Thread):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionFlashHeapAccess):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
* runtime/Options.cpp:
(JSC::overrideDefaults):
* runtime/Options.h:
* runtime/TestRunnerUtils.cpp:
(JSC::finalizeStatsAtEndOfTesting):
Source/WebCore:
Added new tests in JSTests.
The WebCore changes involve:
- Refactoring around new header discipline.
- Adding crazy GC APIs to window.internals to enable us to test the GC's runloop discipline.
* ForwardingHeaders/heap/GCFinalizationCallback.h: Added.
* ForwardingHeaders/heap/IncrementalSweeper.h: Added.
* ForwardingHeaders/heap/MachineStackMarker.h: Added.
* ForwardingHeaders/heap/RunningScope.h: Added.
* bindings/js/CommonVM.cpp:
* testing/Internals.cpp:
(WebCore::Internals::parserMetaData):
(WebCore::Internals::isReadableStreamDisturbed):
(WebCore::Internals::isGCRunning):
(WebCore::Internals::addGCFinalizationCallback):
(WebCore::Internals::stopSweeping):
(WebCore::Internals::startSweeping):
* testing/Internals.h:
* testing/Internals.idl:
Source/WTF:
Extend the use of AbstractLocker so that we can use more locking idioms.
* wtf/AutomaticThread.cpp:
(WTF::AutomaticThreadCondition::notifyOne):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::tryStop):
(WTF::AutomaticThread::isWaiting):
(WTF::AutomaticThread::notify):
(WTF::AutomaticThread::start):
(WTF::AutomaticThread::threadIsStopping):
* wtf/AutomaticThread.h:
* wtf/NumberOfCores.cpp:
(WTF::numberOfProcessorCores):
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::claimTask):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::hasClientWithTask):
(WTF::ParallelHelperPool::getClientWithTask):
* wtf/ParallelHelperPool.h:
Tools:
Make more tests collect continuously.
* Scripts/run-jsc-stress-tests:
Canonical link: https://commits.webkit.org/185692@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@212778 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-02-22 00:58:15 +00:00
|
|
|
bool isWaiting(const AbstractLocker&);
|
2016-12-16 22:26:09 +00:00
|
|
|
|
The collector thread should only start when the mutator doesn't have heap access
https://bugs.webkit.org/show_bug.cgi?id=167737
Reviewed by Keith Miller.
JSTests:
Add versions of splay that flash heap access, to simulate what might happen if a third-party app
was running concurrent GC. In this case, we might actually start the collector thread.
* stress/splay-flash-access-1ms.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
* stress/splay-flash-access.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
Source/JavaScriptCore:
This turns the collector thread's workflow into a state machine, so that the mutator thread can
run it directly. This reduces the amount of synchronization we do with the collector thread, and
means that most apps will never start the collector thread. The collector thread will still start
when we need to finish collecting and we don't have heap access.
In this new world, "stopping the world" means relinquishing control of collection to the mutator.
This means tracking who is conducting collection. I use the GCConductor enum to say who is
conducting. It's either GCConductor::Mutator or GCConductor::Collector. I use the term "conn" to
refer to the concept of conducting (having the conn, relinquishing the conn, taking the conn).
So, stopping the world means giving the mutator the conn. Releasing heap access means giving the
collector the conn.
This meant bringing back the conservative scan of the calling thread. It turns out that this
scan was too slow to be called on each GC increment because apparently setjmp() now does system
calls. So, I wrote our own callee save register saving for the GC. Then I had doubts about
whether or not it was correct, so I also made it so that the GC only rarely asks for the register
state. I think we still want to use my register saving code instead of setjmp because setjmp
seems to save things we don't need, and that could make us overly conservative.
It turns out that this new scheduling discipline makes the old space-time scheduler perform
better than the new stochastic space-time scheduler on systems with fewer than 4 cores. This is
because the mutator having the conn enables us to time the mutator<->collector context switches
by polling. The OS is never involved. So, we can use super precise timing. This allows the old
space-time schduler to shine like it hadn't before.
The splay results imply that this is all a good thing. On 2-core systems, this reduces pause
times by 40% and it increases throughput about 5%. On 1-core systems, this reduces pause times by
half and reduces throughput by 8%. On 4-or-more-core systems, this doesn't seem to have much
effect.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitChildren):
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::ThreadBody::ThreadBody):
(JSC::DFG::Worklist::dump):
(JSC::DFG::numberOfWorklists):
(JSC::DFG::ensureWorklistForIndex):
(JSC::DFG::existingWorklistForIndexOrNull):
(JSC::DFG::existingWorklistForIndex):
* dfg/DFGWorklist.h:
(JSC::DFG::numberOfWorklists): Deleted.
(JSC::DFG::ensureWorklistForIndex): Deleted.
(JSC::DFG::existingWorklistForIndexOrNull): Deleted.
(JSC::DFG::existingWorklistForIndex): Deleted.
* heap/CollectingScope.h: Added.
(JSC::CollectingScope::CollectingScope):
(JSC::CollectingScope::~CollectingScope):
* heap/CollectorPhase.cpp: Added.
(JSC::worldShouldBeSuspended):
(WTF::printInternal):
* heap/CollectorPhase.h: Added.
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::lastGCLength):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
(JSC::FullGCActivityCallback::lastGCLength):
* heap/GCConductor.cpp: Added.
(JSC::gcConductorShortName):
(WTF::printInternal):
* heap/GCConductor.h: Added.
* heap/GCFinalizationCallback.cpp: Added.
(JSC::GCFinalizationCallback::GCFinalizationCallback):
(JSC::GCFinalizationCallback::~GCFinalizationCallback):
* heap/GCFinalizationCallback.h: Added.
(JSC::GCFinalizationCallbackFuncAdaptor::GCFinalizationCallbackFuncAdaptor):
(JSC::createGCFinalizationCallback):
* heap/Heap.cpp:
(JSC::Heap::Thread::Thread):
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::sweepSynchronously):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::shouldCollectInCollectorThread):
(JSC::Heap::collectInCollectorThread):
(JSC::Heap::checkConn):
(JSC::Heap::runNotRunningPhase):
(JSC::Heap::runBeginPhase):
(JSC::Heap::runFixpointPhase):
(JSC::Heap::runConcurrentPhase):
(JSC::Heap::runReloopPhase):
(JSC::Heap::runEndPhase):
(JSC::Heap::changePhase):
(JSC::Heap::finishChangingPhase):
(JSC::Heap::stopThePeriphery):
(JSC::Heap::resumeThePeriphery):
(JSC::Heap::stopTheMutator):
(JSC::Heap::resumeTheMutator):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectInMutatorThread):
(JSC::Heap::waitForCollector):
(JSC::Heap::acquireAccessSlow):
(JSC::Heap::releaseAccessSlow):
(JSC::Heap::relinquishConn):
(JSC::Heap::finishRelinquishingConn):
(JSC::Heap::handleNeedFinalize):
(JSC::Heap::notifyThreadStopping):
(JSC::Heap::finalize):
(JSC::Heap::addFinalizationCallback):
(JSC::Heap::requestCollection):
(JSC::Heap::waitForCollection):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didFinishCollection):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::notifyIsSafeToCollect):
(JSC::Heap::preventCollection):
(JSC::Heap::performIncrement):
(JSC::Heap::markToFixpoint): Deleted.
(JSC::Heap::shouldCollectInThread): Deleted.
(JSC::Heap::collectInThread): Deleted.
(JSC::Heap::stopTheWorld): Deleted.
(JSC::Heap::resumeTheWorld): Deleted.
* heap/Heap.h:
(JSC::Heap::machineThreads):
(JSC::Heap::lastFullGCLength):
(JSC::Heap::lastEdenGCLength):
(JSC::Heap::increaseLastFullGCLength):
* heap/HeapInlines.h:
(JSC::Heap::mutatorIsStopped): Deleted.
* heap/HeapStatistics.cpp: Removed.
* heap/HeapStatistics.h: Removed.
* heap/HelpingGCScope.h: Removed.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::stopSweeping):
(JSC::IncrementalSweeper::willFinishSweeping): Deleted.
* heap/IncrementalSweeper.h:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::gatherConservativeRoots):
(JSC::callWithCurrentThreadState):
* heap/MachineStackMarker.h:
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateSlowCaseImpl):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::sweep):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::sweep):
* heap/MutatorState.cpp:
(WTF::printInternal):
* heap/MutatorState.h:
* heap/RegisterState.h: Added.
* heap/RunningScope.h: Added.
(JSC::RunningScope::RunningScope):
(JSC::RunningScope::~RunningScope):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::SlotVisitor):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::drainInParallelPassively):
(JSC::SlotVisitor::donateAll):
(JSC::SlotVisitor::donate):
* heap/SlotVisitor.h:
(JSC::SlotVisitor::codeName):
* heap/StochasticSpaceTimeMutatorScheduler.cpp:
(JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
(JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
(JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
* heap/SweepingScope.h: Added.
(JSC::SweepingScope::SweepingScope):
(JSC::SweepingScope::~SweepingScope):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Thread::Thread):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionFlashHeapAccess):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
* runtime/Options.cpp:
(JSC::overrideDefaults):
* runtime/Options.h:
* runtime/TestRunnerUtils.cpp:
(JSC::finalizeStatsAtEndOfTesting):
Source/WebCore:
Added new tests in JSTests.
The WebCore changes involve:
- Refactoring around new header discipline.
- Adding crazy GC APIs to window.internals to enable us to test the GC's runloop discipline.
* ForwardingHeaders/heap/GCFinalizationCallback.h: Added.
* ForwardingHeaders/heap/IncrementalSweeper.h: Added.
* ForwardingHeaders/heap/MachineStackMarker.h: Added.
* ForwardingHeaders/heap/RunningScope.h: Added.
* bindings/js/CommonVM.cpp:
* testing/Internals.cpp:
(WebCore::Internals::parserMetaData):
(WebCore::Internals::isReadableStreamDisturbed):
(WebCore::Internals::isGCRunning):
(WebCore::Internals::addGCFinalizationCallback):
(WebCore::Internals::stopSweeping):
(WebCore::Internals::startSweeping):
* testing/Internals.h:
* testing/Internals.idl:
Source/WTF:
Extend the use of AbstractLocker so that we can use more locking idioms.
* wtf/AutomaticThread.cpp:
(WTF::AutomaticThreadCondition::notifyOne):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::tryStop):
(WTF::AutomaticThread::isWaiting):
(WTF::AutomaticThread::notify):
(WTF::AutomaticThread::start):
(WTF::AutomaticThread::threadIsStopping):
* wtf/AutomaticThread.h:
* wtf/NumberOfCores.cpp:
(WTF::numberOfProcessorCores):
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::claimTask):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::hasClientWithTask):
(WTF::ParallelHelperPool::getClientWithTask):
* wtf/ParallelHelperPool.h:
Tools:
Make more tests collect continuously.
* Scripts/run-jsc-stress-tests:
Canonical link: https://commits.webkit.org/185692@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@212778 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-02-22 00:58:15 +00:00
|
|
|
bool notify(const AbstractLocker&);
|
2016-12-16 22:26:09 +00:00
|
|
|
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
void join();
|
2018-06-13 19:07:22 +00:00
|
|
|
|
|
|
|
virtual const char* name() const { return "WTF::AutomaticThread"; }
|
|
|
|
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
protected:
|
|
|
|
// This logically creates the thread, but in reality the thread won't be created until someone
|
2016-10-19 17:47:30 +00:00
|
|
|
// calls AutomaticThreadCondition::notifyOne() or notifyAll().
|
2021-05-26 16:46:37 +00:00
|
|
|
AutomaticThread(const AbstractLocker&, Box<Lock>, Ref<AutomaticThreadCondition>&&, Seconds timeout = 10_s);
|
2020-05-07 19:49:37 +00:00
|
|
|
|
2021-05-26 16:46:37 +00:00
|
|
|
AutomaticThread(const AbstractLocker&, Box<Lock>, Ref<AutomaticThreadCondition>&&, ThreadType, Seconds timeout = 10_s);
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
|
|
|
|
// To understand PollResult and WorkResult, imagine that poll() and work() are being called like
|
|
|
|
// so:
|
|
|
|
//
|
|
|
|
// void AutomaticThread::runThread()
|
|
|
|
// {
|
|
|
|
// for (;;) {
|
|
|
|
// {
|
2021-05-22 16:49:42 +00:00
|
|
|
// Locker locker { m_lock };
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
// for (;;) {
|
|
|
|
// PollResult result = poll();
|
|
|
|
// if (result == PollResult::Work)
|
|
|
|
// break;
|
|
|
|
// if (result == PollResult::Stop)
|
|
|
|
// return;
|
|
|
|
// RELEASE_ASSERT(result == PollResult::Wait);
|
|
|
|
// m_condition.wait(m_lock);
|
|
|
|
// }
|
|
|
|
// }
|
|
|
|
//
|
|
|
|
// WorkResult result = work();
|
|
|
|
// if (result == WorkResult::Stop)
|
|
|
|
// return;
|
|
|
|
// RELEASE_ASSERT(result == WorkResult::Continue);
|
|
|
|
// }
|
|
|
|
// }
|
|
|
|
|
|
|
|
enum class PollResult { Work, Stop, Wait };
|
The collector thread should only start when the mutator doesn't have heap access
https://bugs.webkit.org/show_bug.cgi?id=167737
Reviewed by Keith Miller.
JSTests:
Add versions of splay that flash heap access, to simulate what might happen if a third-party app
was running concurrent GC. In this case, we might actually start the collector thread.
* stress/splay-flash-access-1ms.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
* stress/splay-flash-access.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
Source/JavaScriptCore:
This turns the collector thread's workflow into a state machine, so that the mutator thread can
run it directly. This reduces the amount of synchronization we do with the collector thread, and
means that most apps will never start the collector thread. The collector thread will still start
when we need to finish collecting and we don't have heap access.
In this new world, "stopping the world" means relinquishing control of collection to the mutator.
This means tracking who is conducting collection. I use the GCConductor enum to say who is
conducting. It's either GCConductor::Mutator or GCConductor::Collector. I use the term "conn" to
refer to the concept of conducting (having the conn, relinquishing the conn, taking the conn).
So, stopping the world means giving the mutator the conn. Releasing heap access means giving the
collector the conn.
This meant bringing back the conservative scan of the calling thread. It turns out that this
scan was too slow to be called on each GC increment because apparently setjmp() now does system
calls. So, I wrote our own callee save register saving for the GC. Then I had doubts about
whether or not it was correct, so I also made it so that the GC only rarely asks for the register
state. I think we still want to use my register saving code instead of setjmp because setjmp
seems to save things we don't need, and that could make us overly conservative.
It turns out that this new scheduling discipline makes the old space-time scheduler perform
better than the new stochastic space-time scheduler on systems with fewer than 4 cores. This is
because the mutator having the conn enables us to time the mutator<->collector context switches
by polling. The OS is never involved. So, we can use super precise timing. This allows the old
space-time schduler to shine like it hadn't before.
The splay results imply that this is all a good thing. On 2-core systems, this reduces pause
times by 40% and it increases throughput about 5%. On 1-core systems, this reduces pause times by
half and reduces throughput by 8%. On 4-or-more-core systems, this doesn't seem to have much
effect.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitChildren):
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::ThreadBody::ThreadBody):
(JSC::DFG::Worklist::dump):
(JSC::DFG::numberOfWorklists):
(JSC::DFG::ensureWorklistForIndex):
(JSC::DFG::existingWorklistForIndexOrNull):
(JSC::DFG::existingWorklistForIndex):
* dfg/DFGWorklist.h:
(JSC::DFG::numberOfWorklists): Deleted.
(JSC::DFG::ensureWorklistForIndex): Deleted.
(JSC::DFG::existingWorklistForIndexOrNull): Deleted.
(JSC::DFG::existingWorklistForIndex): Deleted.
* heap/CollectingScope.h: Added.
(JSC::CollectingScope::CollectingScope):
(JSC::CollectingScope::~CollectingScope):
* heap/CollectorPhase.cpp: Added.
(JSC::worldShouldBeSuspended):
(WTF::printInternal):
* heap/CollectorPhase.h: Added.
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::lastGCLength):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
(JSC::FullGCActivityCallback::lastGCLength):
* heap/GCConductor.cpp: Added.
(JSC::gcConductorShortName):
(WTF::printInternal):
* heap/GCConductor.h: Added.
* heap/GCFinalizationCallback.cpp: Added.
(JSC::GCFinalizationCallback::GCFinalizationCallback):
(JSC::GCFinalizationCallback::~GCFinalizationCallback):
* heap/GCFinalizationCallback.h: Added.
(JSC::GCFinalizationCallbackFuncAdaptor::GCFinalizationCallbackFuncAdaptor):
(JSC::createGCFinalizationCallback):
* heap/Heap.cpp:
(JSC::Heap::Thread::Thread):
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::sweepSynchronously):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::shouldCollectInCollectorThread):
(JSC::Heap::collectInCollectorThread):
(JSC::Heap::checkConn):
(JSC::Heap::runNotRunningPhase):
(JSC::Heap::runBeginPhase):
(JSC::Heap::runFixpointPhase):
(JSC::Heap::runConcurrentPhase):
(JSC::Heap::runReloopPhase):
(JSC::Heap::runEndPhase):
(JSC::Heap::changePhase):
(JSC::Heap::finishChangingPhase):
(JSC::Heap::stopThePeriphery):
(JSC::Heap::resumeThePeriphery):
(JSC::Heap::stopTheMutator):
(JSC::Heap::resumeTheMutator):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectInMutatorThread):
(JSC::Heap::waitForCollector):
(JSC::Heap::acquireAccessSlow):
(JSC::Heap::releaseAccessSlow):
(JSC::Heap::relinquishConn):
(JSC::Heap::finishRelinquishingConn):
(JSC::Heap::handleNeedFinalize):
(JSC::Heap::notifyThreadStopping):
(JSC::Heap::finalize):
(JSC::Heap::addFinalizationCallback):
(JSC::Heap::requestCollection):
(JSC::Heap::waitForCollection):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didFinishCollection):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::notifyIsSafeToCollect):
(JSC::Heap::preventCollection):
(JSC::Heap::performIncrement):
(JSC::Heap::markToFixpoint): Deleted.
(JSC::Heap::shouldCollectInThread): Deleted.
(JSC::Heap::collectInThread): Deleted.
(JSC::Heap::stopTheWorld): Deleted.
(JSC::Heap::resumeTheWorld): Deleted.
* heap/Heap.h:
(JSC::Heap::machineThreads):
(JSC::Heap::lastFullGCLength):
(JSC::Heap::lastEdenGCLength):
(JSC::Heap::increaseLastFullGCLength):
* heap/HeapInlines.h:
(JSC::Heap::mutatorIsStopped): Deleted.
* heap/HeapStatistics.cpp: Removed.
* heap/HeapStatistics.h: Removed.
* heap/HelpingGCScope.h: Removed.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::stopSweeping):
(JSC::IncrementalSweeper::willFinishSweeping): Deleted.
* heap/IncrementalSweeper.h:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::gatherConservativeRoots):
(JSC::callWithCurrentThreadState):
* heap/MachineStackMarker.h:
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateSlowCaseImpl):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::sweep):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::sweep):
* heap/MutatorState.cpp:
(WTF::printInternal):
* heap/MutatorState.h:
* heap/RegisterState.h: Added.
* heap/RunningScope.h: Added.
(JSC::RunningScope::RunningScope):
(JSC::RunningScope::~RunningScope):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::SlotVisitor):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::drainInParallelPassively):
(JSC::SlotVisitor::donateAll):
(JSC::SlotVisitor::donate):
* heap/SlotVisitor.h:
(JSC::SlotVisitor::codeName):
* heap/StochasticSpaceTimeMutatorScheduler.cpp:
(JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
(JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
(JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
* heap/SweepingScope.h: Added.
(JSC::SweepingScope::SweepingScope):
(JSC::SweepingScope::~SweepingScope):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Thread::Thread):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionFlashHeapAccess):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
* runtime/Options.cpp:
(JSC::overrideDefaults):
* runtime/Options.h:
* runtime/TestRunnerUtils.cpp:
(JSC::finalizeStatsAtEndOfTesting):
Source/WebCore:
Added new tests in JSTests.
The WebCore changes involve:
- Refactoring around new header discipline.
- Adding crazy GC APIs to window.internals to enable us to test the GC's runloop discipline.
* ForwardingHeaders/heap/GCFinalizationCallback.h: Added.
* ForwardingHeaders/heap/IncrementalSweeper.h: Added.
* ForwardingHeaders/heap/MachineStackMarker.h: Added.
* ForwardingHeaders/heap/RunningScope.h: Added.
* bindings/js/CommonVM.cpp:
* testing/Internals.cpp:
(WebCore::Internals::parserMetaData):
(WebCore::Internals::isReadableStreamDisturbed):
(WebCore::Internals::isGCRunning):
(WebCore::Internals::addGCFinalizationCallback):
(WebCore::Internals::stopSweeping):
(WebCore::Internals::startSweeping):
* testing/Internals.h:
* testing/Internals.idl:
Source/WTF:
Extend the use of AbstractLocker so that we can use more locking idioms.
* wtf/AutomaticThread.cpp:
(WTF::AutomaticThreadCondition::notifyOne):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::tryStop):
(WTF::AutomaticThread::isWaiting):
(WTF::AutomaticThread::notify):
(WTF::AutomaticThread::start):
(WTF::AutomaticThread::threadIsStopping):
* wtf/AutomaticThread.h:
* wtf/NumberOfCores.cpp:
(WTF::numberOfProcessorCores):
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::claimTask):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::hasClientWithTask):
(WTF::ParallelHelperPool::getClientWithTask):
* wtf/ParallelHelperPool.h:
Tools:
Make more tests collect continuously.
* Scripts/run-jsc-stress-tests:
Canonical link: https://commits.webkit.org/185692@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@212778 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-02-22 00:58:15 +00:00
|
|
|
virtual PollResult poll(const AbstractLocker&) = 0;
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
|
|
|
|
enum class WorkResult { Continue, Stop };
|
|
|
|
virtual WorkResult work() = 0;
|
|
|
|
|
2016-10-19 17:47:30 +00:00
|
|
|
// It's sometimes useful to allocate resources while the thread is running, and to destroy them
|
|
|
|
// when the thread dies. These methods let you do this. You can override these methods, and you
|
|
|
|
// can be sure that the default ones don't do anything (so you don't need a super call).
|
|
|
|
virtual void threadDidStart();
|
The collector thread should only start when the mutator doesn't have heap access
https://bugs.webkit.org/show_bug.cgi?id=167737
Reviewed by Keith Miller.
JSTests:
Add versions of splay that flash heap access, to simulate what might happen if a third-party app
was running concurrent GC. In this case, we might actually start the collector thread.
* stress/splay-flash-access-1ms.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
* stress/splay-flash-access.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
Source/JavaScriptCore:
This turns the collector thread's workflow into a state machine, so that the mutator thread can
run it directly. This reduces the amount of synchronization we do with the collector thread, and
means that most apps will never start the collector thread. The collector thread will still start
when we need to finish collecting and we don't have heap access.
In this new world, "stopping the world" means relinquishing control of collection to the mutator.
This means tracking who is conducting collection. I use the GCConductor enum to say who is
conducting. It's either GCConductor::Mutator or GCConductor::Collector. I use the term "conn" to
refer to the concept of conducting (having the conn, relinquishing the conn, taking the conn).
So, stopping the world means giving the mutator the conn. Releasing heap access means giving the
collector the conn.
This meant bringing back the conservative scan of the calling thread. It turns out that this
scan was too slow to be called on each GC increment because apparently setjmp() now does system
calls. So, I wrote our own callee save register saving for the GC. Then I had doubts about
whether or not it was correct, so I also made it so that the GC only rarely asks for the register
state. I think we still want to use my register saving code instead of setjmp because setjmp
seems to save things we don't need, and that could make us overly conservative.
It turns out that this new scheduling discipline makes the old space-time scheduler perform
better than the new stochastic space-time scheduler on systems with fewer than 4 cores. This is
because the mutator having the conn enables us to time the mutator<->collector context switches
by polling. The OS is never involved. So, we can use super precise timing. This allows the old
space-time schduler to shine like it hadn't before.
The splay results imply that this is all a good thing. On 2-core systems, this reduces pause
times by 40% and it increases throughput about 5%. On 1-core systems, this reduces pause times by
half and reduces throughput by 8%. On 4-or-more-core systems, this doesn't seem to have much
effect.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitChildren):
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::ThreadBody::ThreadBody):
(JSC::DFG::Worklist::dump):
(JSC::DFG::numberOfWorklists):
(JSC::DFG::ensureWorklistForIndex):
(JSC::DFG::existingWorklistForIndexOrNull):
(JSC::DFG::existingWorklistForIndex):
* dfg/DFGWorklist.h:
(JSC::DFG::numberOfWorklists): Deleted.
(JSC::DFG::ensureWorklistForIndex): Deleted.
(JSC::DFG::existingWorklistForIndexOrNull): Deleted.
(JSC::DFG::existingWorklistForIndex): Deleted.
* heap/CollectingScope.h: Added.
(JSC::CollectingScope::CollectingScope):
(JSC::CollectingScope::~CollectingScope):
* heap/CollectorPhase.cpp: Added.
(JSC::worldShouldBeSuspended):
(WTF::printInternal):
* heap/CollectorPhase.h: Added.
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::lastGCLength):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
(JSC::FullGCActivityCallback::lastGCLength):
* heap/GCConductor.cpp: Added.
(JSC::gcConductorShortName):
(WTF::printInternal):
* heap/GCConductor.h: Added.
* heap/GCFinalizationCallback.cpp: Added.
(JSC::GCFinalizationCallback::GCFinalizationCallback):
(JSC::GCFinalizationCallback::~GCFinalizationCallback):
* heap/GCFinalizationCallback.h: Added.
(JSC::GCFinalizationCallbackFuncAdaptor::GCFinalizationCallbackFuncAdaptor):
(JSC::createGCFinalizationCallback):
* heap/Heap.cpp:
(JSC::Heap::Thread::Thread):
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::sweepSynchronously):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::shouldCollectInCollectorThread):
(JSC::Heap::collectInCollectorThread):
(JSC::Heap::checkConn):
(JSC::Heap::runNotRunningPhase):
(JSC::Heap::runBeginPhase):
(JSC::Heap::runFixpointPhase):
(JSC::Heap::runConcurrentPhase):
(JSC::Heap::runReloopPhase):
(JSC::Heap::runEndPhase):
(JSC::Heap::changePhase):
(JSC::Heap::finishChangingPhase):
(JSC::Heap::stopThePeriphery):
(JSC::Heap::resumeThePeriphery):
(JSC::Heap::stopTheMutator):
(JSC::Heap::resumeTheMutator):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectInMutatorThread):
(JSC::Heap::waitForCollector):
(JSC::Heap::acquireAccessSlow):
(JSC::Heap::releaseAccessSlow):
(JSC::Heap::relinquishConn):
(JSC::Heap::finishRelinquishingConn):
(JSC::Heap::handleNeedFinalize):
(JSC::Heap::notifyThreadStopping):
(JSC::Heap::finalize):
(JSC::Heap::addFinalizationCallback):
(JSC::Heap::requestCollection):
(JSC::Heap::waitForCollection):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didFinishCollection):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::notifyIsSafeToCollect):
(JSC::Heap::preventCollection):
(JSC::Heap::performIncrement):
(JSC::Heap::markToFixpoint): Deleted.
(JSC::Heap::shouldCollectInThread): Deleted.
(JSC::Heap::collectInThread): Deleted.
(JSC::Heap::stopTheWorld): Deleted.
(JSC::Heap::resumeTheWorld): Deleted.
* heap/Heap.h:
(JSC::Heap::machineThreads):
(JSC::Heap::lastFullGCLength):
(JSC::Heap::lastEdenGCLength):
(JSC::Heap::increaseLastFullGCLength):
* heap/HeapInlines.h:
(JSC::Heap::mutatorIsStopped): Deleted.
* heap/HeapStatistics.cpp: Removed.
* heap/HeapStatistics.h: Removed.
* heap/HelpingGCScope.h: Removed.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::stopSweeping):
(JSC::IncrementalSweeper::willFinishSweeping): Deleted.
* heap/IncrementalSweeper.h:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::gatherConservativeRoots):
(JSC::callWithCurrentThreadState):
* heap/MachineStackMarker.h:
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateSlowCaseImpl):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::sweep):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::sweep):
* heap/MutatorState.cpp:
(WTF::printInternal):
* heap/MutatorState.h:
* heap/RegisterState.h: Added.
* heap/RunningScope.h: Added.
(JSC::RunningScope::RunningScope):
(JSC::RunningScope::~RunningScope):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::SlotVisitor):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::drainInParallelPassively):
(JSC::SlotVisitor::donateAll):
(JSC::SlotVisitor::donate):
* heap/SlotVisitor.h:
(JSC::SlotVisitor::codeName):
* heap/StochasticSpaceTimeMutatorScheduler.cpp:
(JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
(JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
(JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
* heap/SweepingScope.h: Added.
(JSC::SweepingScope::SweepingScope):
(JSC::SweepingScope::~SweepingScope):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Thread::Thread):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionFlashHeapAccess):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
* runtime/Options.cpp:
(JSC::overrideDefaults):
* runtime/Options.h:
* runtime/TestRunnerUtils.cpp:
(JSC::finalizeStatsAtEndOfTesting):
Source/WebCore:
Added new tests in JSTests.
The WebCore changes involve:
- Refactoring around new header discipline.
- Adding crazy GC APIs to window.internals to enable us to test the GC's runloop discipline.
* ForwardingHeaders/heap/GCFinalizationCallback.h: Added.
* ForwardingHeaders/heap/IncrementalSweeper.h: Added.
* ForwardingHeaders/heap/MachineStackMarker.h: Added.
* ForwardingHeaders/heap/RunningScope.h: Added.
* bindings/js/CommonVM.cpp:
* testing/Internals.cpp:
(WebCore::Internals::parserMetaData):
(WebCore::Internals::isReadableStreamDisturbed):
(WebCore::Internals::isGCRunning):
(WebCore::Internals::addGCFinalizationCallback):
(WebCore::Internals::stopSweeping):
(WebCore::Internals::startSweeping):
* testing/Internals.h:
* testing/Internals.idl:
Source/WTF:
Extend the use of AbstractLocker so that we can use more locking idioms.
* wtf/AutomaticThread.cpp:
(WTF::AutomaticThreadCondition::notifyOne):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::tryStop):
(WTF::AutomaticThread::isWaiting):
(WTF::AutomaticThread::notify):
(WTF::AutomaticThread::start):
(WTF::AutomaticThread::threadIsStopping):
* wtf/AutomaticThread.h:
* wtf/NumberOfCores.cpp:
(WTF::numberOfProcessorCores):
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::claimTask):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::hasClientWithTask):
(WTF::ParallelHelperPool::getClientWithTask):
* wtf/ParallelHelperPool.h:
Tools:
Make more tests collect continuously.
* Scripts/run-jsc-stress-tests:
Canonical link: https://commits.webkit.org/185692@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@212778 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-02-22 00:58:15 +00:00
|
|
|
virtual void threadIsStopping(const AbstractLocker&);
|
2018-06-08 08:47:06 +00:00
|
|
|
|
|
|
|
// Control whether this automatic thread should sleep when timeout happens.
|
|
|
|
// By overriding this function, we can customize how automatic threads will sleep.
|
|
|
|
// For example, when you have thread pool, you can decrease active threads moderately.
|
|
|
|
virtual bool shouldSleep(const AbstractLocker&) { return true; }
|
2016-10-19 17:47:30 +00:00
|
|
|
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
private:
|
|
|
|
friend class AutomaticThreadCondition;
|
|
|
|
|
The collector thread should only start when the mutator doesn't have heap access
https://bugs.webkit.org/show_bug.cgi?id=167737
Reviewed by Keith Miller.
JSTests:
Add versions of splay that flash heap access, to simulate what might happen if a third-party app
was running concurrent GC. In this case, we might actually start the collector thread.
* stress/splay-flash-access-1ms.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
* stress/splay-flash-access.js: Added.
(performance.now):
(this.Setup.setup.setup):
(this.TearDown.tearDown.tearDown):
(Benchmark):
(BenchmarkResult):
(BenchmarkResult.prototype.valueOf):
(BenchmarkSuite):
(alert):
(Math.random):
(BenchmarkSuite.ResetRNG):
(RunStep):
(BenchmarkSuite.RunSuites):
(BenchmarkSuite.CountBenchmarks):
(BenchmarkSuite.GeometricMean):
(BenchmarkSuite.GeometricMeanTime):
(BenchmarkSuite.AverageAbovePercentile):
(BenchmarkSuite.GeometricMeanLatency):
(BenchmarkSuite.FormatScore):
(BenchmarkSuite.prototype.NotifyStep):
(BenchmarkSuite.prototype.NotifyResult):
(BenchmarkSuite.prototype.NotifyError):
(BenchmarkSuite.prototype.RunSingleBenchmark):
(RunNextSetup):
(RunNextBenchmark):
(RunNextTearDown):
(BenchmarkSuite.prototype.RunStep):
(GeneratePayloadTree):
(GenerateKey):
(SplayUpdateStats):
(InsertNewNode):
(SplaySetup):
(SplayTearDown):
(SplayRun):
(SplayTree):
(SplayTree.prototype.isEmpty):
(SplayTree.prototype.insert):
(SplayTree.prototype.remove):
(SplayTree.prototype.find):
(SplayTree.prototype.findMax):
(SplayTree.prototype.findGreatestLessThan):
(SplayTree.prototype.exportKeys):
(SplayTree.prototype.splay_):
(SplayTree.Node):
(SplayTree.Node.prototype.traverse_):
(jscSetUp):
(jscTearDown):
(jscRun):
(averageAbovePercentile):
(printPercentile):
Source/JavaScriptCore:
This turns the collector thread's workflow into a state machine, so that the mutator thread can
run it directly. This reduces the amount of synchronization we do with the collector thread, and
means that most apps will never start the collector thread. The collector thread will still start
when we need to finish collecting and we don't have heap access.
In this new world, "stopping the world" means relinquishing control of collection to the mutator.
This means tracking who is conducting collection. I use the GCConductor enum to say who is
conducting. It's either GCConductor::Mutator or GCConductor::Collector. I use the term "conn" to
refer to the concept of conducting (having the conn, relinquishing the conn, taking the conn).
So, stopping the world means giving the mutator the conn. Releasing heap access means giving the
collector the conn.
This meant bringing back the conservative scan of the calling thread. It turns out that this
scan was too slow to be called on each GC increment because apparently setjmp() now does system
calls. So, I wrote our own callee save register saving for the GC. Then I had doubts about
whether or not it was correct, so I also made it so that the GC only rarely asks for the register
state. I think we still want to use my register saving code instead of setjmp because setjmp
seems to save things we don't need, and that could make us overly conservative.
It turns out that this new scheduling discipline makes the old space-time scheduler perform
better than the new stochastic space-time scheduler on systems with fewer than 4 cores. This is
because the mutator having the conn enables us to time the mutator<->collector context switches
by polling. The OS is never involved. So, we can use super precise timing. This allows the old
space-time schduler to shine like it hadn't before.
The splay results imply that this is all a good thing. On 2-core systems, this reduces pause
times by 40% and it increases throughput about 5%. On 1-core systems, this reduces pause times by
half and reduces throughput by 8%. On 4-or-more-core systems, this doesn't seem to have much
effect.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitChildren):
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::ThreadBody::ThreadBody):
(JSC::DFG::Worklist::dump):
(JSC::DFG::numberOfWorklists):
(JSC::DFG::ensureWorklistForIndex):
(JSC::DFG::existingWorklistForIndexOrNull):
(JSC::DFG::existingWorklistForIndex):
* dfg/DFGWorklist.h:
(JSC::DFG::numberOfWorklists): Deleted.
(JSC::DFG::ensureWorklistForIndex): Deleted.
(JSC::DFG::existingWorklistForIndexOrNull): Deleted.
(JSC::DFG::existingWorklistForIndex): Deleted.
* heap/CollectingScope.h: Added.
(JSC::CollectingScope::CollectingScope):
(JSC::CollectingScope::~CollectingScope):
* heap/CollectorPhase.cpp: Added.
(JSC::worldShouldBeSuspended):
(WTF::printInternal):
* heap/CollectorPhase.h: Added.
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::lastGCLength):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
(JSC::FullGCActivityCallback::lastGCLength):
* heap/GCConductor.cpp: Added.
(JSC::gcConductorShortName):
(WTF::printInternal):
* heap/GCConductor.h: Added.
* heap/GCFinalizationCallback.cpp: Added.
(JSC::GCFinalizationCallback::GCFinalizationCallback):
(JSC::GCFinalizationCallback::~GCFinalizationCallback):
* heap/GCFinalizationCallback.h: Added.
(JSC::GCFinalizationCallbackFuncAdaptor::GCFinalizationCallbackFuncAdaptor):
(JSC::createGCFinalizationCallback):
* heap/Heap.cpp:
(JSC::Heap::Thread::Thread):
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::sweepSynchronously):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::shouldCollectInCollectorThread):
(JSC::Heap::collectInCollectorThread):
(JSC::Heap::checkConn):
(JSC::Heap::runNotRunningPhase):
(JSC::Heap::runBeginPhase):
(JSC::Heap::runFixpointPhase):
(JSC::Heap::runConcurrentPhase):
(JSC::Heap::runReloopPhase):
(JSC::Heap::runEndPhase):
(JSC::Heap::changePhase):
(JSC::Heap::finishChangingPhase):
(JSC::Heap::stopThePeriphery):
(JSC::Heap::resumeThePeriphery):
(JSC::Heap::stopTheMutator):
(JSC::Heap::resumeTheMutator):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectInMutatorThread):
(JSC::Heap::waitForCollector):
(JSC::Heap::acquireAccessSlow):
(JSC::Heap::releaseAccessSlow):
(JSC::Heap::relinquishConn):
(JSC::Heap::finishRelinquishingConn):
(JSC::Heap::handleNeedFinalize):
(JSC::Heap::notifyThreadStopping):
(JSC::Heap::finalize):
(JSC::Heap::addFinalizationCallback):
(JSC::Heap::requestCollection):
(JSC::Heap::waitForCollection):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didFinishCollection):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::notifyIsSafeToCollect):
(JSC::Heap::preventCollection):
(JSC::Heap::performIncrement):
(JSC::Heap::markToFixpoint): Deleted.
(JSC::Heap::shouldCollectInThread): Deleted.
(JSC::Heap::collectInThread): Deleted.
(JSC::Heap::stopTheWorld): Deleted.
(JSC::Heap::resumeTheWorld): Deleted.
* heap/Heap.h:
(JSC::Heap::machineThreads):
(JSC::Heap::lastFullGCLength):
(JSC::Heap::lastEdenGCLength):
(JSC::Heap::increaseLastFullGCLength):
* heap/HeapInlines.h:
(JSC::Heap::mutatorIsStopped): Deleted.
* heap/HeapStatistics.cpp: Removed.
* heap/HeapStatistics.h: Removed.
* heap/HelpingGCScope.h: Removed.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::stopSweeping):
(JSC::IncrementalSweeper::willFinishSweeping): Deleted.
* heap/IncrementalSweeper.h:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::gatherConservativeRoots):
(JSC::callWithCurrentThreadState):
* heap/MachineStackMarker.h:
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateSlowCaseImpl):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::sweep):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::sweep):
* heap/MutatorState.cpp:
(WTF::printInternal):
* heap/MutatorState.h:
* heap/RegisterState.h: Added.
* heap/RunningScope.h: Added.
(JSC::RunningScope::RunningScope):
(JSC::RunningScope::~RunningScope):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::SlotVisitor):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::drainInParallelPassively):
(JSC::SlotVisitor::donateAll):
(JSC::SlotVisitor::donate):
* heap/SlotVisitor.h:
(JSC::SlotVisitor::codeName):
* heap/StochasticSpaceTimeMutatorScheduler.cpp:
(JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
(JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
(JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
* heap/SweepingScope.h: Added.
(JSC::SweepingScope::SweepingScope):
(JSC::SweepingScope::~SweepingScope):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Thread::Thread):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionFlashHeapAccess):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
* runtime/Options.cpp:
(JSC::overrideDefaults):
* runtime/Options.h:
* runtime/TestRunnerUtils.cpp:
(JSC::finalizeStatsAtEndOfTesting):
Source/WebCore:
Added new tests in JSTests.
The WebCore changes involve:
- Refactoring around new header discipline.
- Adding crazy GC APIs to window.internals to enable us to test the GC's runloop discipline.
* ForwardingHeaders/heap/GCFinalizationCallback.h: Added.
* ForwardingHeaders/heap/IncrementalSweeper.h: Added.
* ForwardingHeaders/heap/MachineStackMarker.h: Added.
* ForwardingHeaders/heap/RunningScope.h: Added.
* bindings/js/CommonVM.cpp:
* testing/Internals.cpp:
(WebCore::Internals::parserMetaData):
(WebCore::Internals::isReadableStreamDisturbed):
(WebCore::Internals::isGCRunning):
(WebCore::Internals::addGCFinalizationCallback):
(WebCore::Internals::stopSweeping):
(WebCore::Internals::startSweeping):
* testing/Internals.h:
* testing/Internals.idl:
Source/WTF:
Extend the use of AbstractLocker so that we can use more locking idioms.
* wtf/AutomaticThread.cpp:
(WTF::AutomaticThreadCondition::notifyOne):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::tryStop):
(WTF::AutomaticThread::isWaiting):
(WTF::AutomaticThread::notify):
(WTF::AutomaticThread::start):
(WTF::AutomaticThread::threadIsStopping):
* wtf/AutomaticThread.h:
* wtf/NumberOfCores.cpp:
(WTF::numberOfProcessorCores):
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::claimTask):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::hasClientWithTask):
(WTF::ParallelHelperPool::getClientWithTask):
* wtf/ParallelHelperPool.h:
Tools:
Make more tests collect continuously.
* Scripts/run-jsc-stress-tests:
Canonical link: https://commits.webkit.org/185692@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@212778 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-02-22 00:58:15 +00:00
|
|
|
void start(const AbstractLocker&);
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
|
2021-05-26 16:46:37 +00:00
|
|
|
Box<Lock> m_lock;
|
2018-06-23 09:59:04 +00:00
|
|
|
Ref<AutomaticThreadCondition> m_condition;
|
2018-06-08 08:47:06 +00:00
|
|
|
Seconds m_timeout;
|
2020-05-07 19:49:37 +00:00
|
|
|
ThreadType m_threadType { ThreadType::Unknown };
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
bool m_isRunning { true };
|
2016-12-16 22:26:09 +00:00
|
|
|
bool m_isWaiting { false };
|
The GC should be in a thread
https://bugs.webkit.org/show_bug.cgi?id=163562
Reviewed by Geoffrey Garen and Andreas Kling.
Source/JavaScriptCore:
In a concurrent GC, the work of collecting happens on a separate thread. This patch
implements this, and schedules the thread the way that a concurrent GC thread would be
scheduled. But, the GC isn't actually concurrent yet because it calls stopTheWorld() before
doing anything and calls resumeTheWorld() after it's done with everything. The next step will
be to make it really concurrent by basically calling stopTheWorld()/resumeTheWorld() around
bounded snippets of work while making most of the work happen with the world running. Our GC
will probably always have stop-the-world phases because the semantics of JSC weak references
call for it.
This implements concurrent GC scheduling. This means that there is no longer a
Heap::collect() API. Instead, you can call collectAsync() which makes sure that a GC is
scheduled (it will do nothing if one is scheduled or ongoing) or you can call collectSync()
to schedule a GC and wait for it to happen. I made our debugging stuff call collectSync().
It should be a goal to never call collectSync() except for debugging or benchmark harness
hacks.
The collector thread is an AutomaticThread, so it won't linger when not in use. It works on
a ticket-based system, like you would see at the DMV. A ticket is a 64-bit integer. There are
two ticket counters: last granted and last served. When you request a collection, last
granted is incremented and its new value given to you. When a collection completes, last
served is incremented. collectSync() waits until last served catches up to what last granted
had been at the time you requested a GC. This means that if you request a sync GC in the
middle of an async GC, you will wait for that async GC to finish and then you will request
and wait for your sync GC.
The synchronization between the collector thread and the main threads is complex. The
collector thread needs to be able to ask the main thread to stop. It needs to be able to do
some post-GC clean-up, like the synchronous CodeBlock and LargeAllocation sweeps, on the main
thread. The collector needs to be able to ask the main thread to execute a cross-modifying
code fence before running any JIT code, since the GC might aid the JIT worklist and run JIT
finalization. It's possible for the GC to want the main thread to run something at the same
time that the main thread wants to wait for the GC. The main thread needs to be able to run
non-JSC stuff without causing the GC to completely stall. The main thread needs to be able
to query its own state (is there a request to stop?) and change it (running JSC versus not)
quickly, since this may happen on hot paths. This kind of intertwined system of requests,
notifications, and state changes requires a combination of lock-free algorithms and waiting.
So, this is all implemented using a Atomic<unsigned> Heap::m_worldState, which has bits to
represent things being requested by the collector and the heap access state of the mutator. I
am borrowing a lot of terms that I've seen in other VMs that I've worked on. Here's what they
mean:
- Stop the world: make sure that either the mutator is not running, or that it's not running
code that could mess with the heap.
- Heap access: the mutator is said to have heap access if it could mess with the heap.
If you stop the world and the mutator doesn't have heap access, all you're doing is making
sure that it will block when it tries to acquire heap access. This means that our GC is
already fully concurrent in cases where the GC is requested while the mutator has no heap
access. This probably won't happen, but if it did then it should just work. Usually, stopping
the world means that we state our shouldStop request with m_worldState, and a future call
to Heap::stopIfNecessary() will go to slow path and stop. The act of stopping or waiting to
acquire heap access is managed by using ParkingLot API directly on m_worldState. This works
out great because it would be very awkward to get the same functionality using locks and
condition variables, since we want stopIfNecessary/acquireAccess/requestAccess fast paths
that are single atomic instructions (load/CAS/CAS, respectively). The mutator will call these
things frequently. Currently we have Heap::stopIfNecessary() polling on every allocator slow
path, but we may want to make it even more frequent than that.
Currently only JSC API clients benefit from the heap access optimization. The DOM forces us
to assume that heap access is permanently on, since DOM manipulation doesn't always hold the
JSLock. We could still allow the GC to proceed when the runloop is idle by having the GC put
a task on the runloop that just calls stopIfNecessary().
This is perf neutral. The only behavior change that clients ought to observe is that marking
and the weak fixpoint happen on a separate thread. Marking was already parallel so it already
handled multiple threads, but now it _never_ runs on the main thread. The weak fixpoint
needed some help to be able to run on another thread - mostly because there was some code in
IndexedDB that was using thread specifics in the weak fixpoint.
* API/JSBase.cpp:
(JSSynchronousEdenCollectForDebugging):
* API/JSManagedValue.mm:
(-[JSManagedValue initWithValue:]):
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::doCollection):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
* heap/Heap.cpp:
(JSC::Heap::Thread::Thread):
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::markRoots):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::deleteUnmarkedCompiledCode):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::shouldCollectInThread):
(JSC::Heap::collectInThread):
(JSC::Heap::stopTheWorld):
(JSC::Heap::resumeTheWorld):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::acquireAccessSlow):
(JSC::Heap::releaseAccessSlow):
(JSC::Heap::handleDidJIT):
(JSC::Heap::handleNeedFinalize):
(JSC::Heap::setDidJIT):
(JSC::Heap::setNeedFinalize):
(JSC::Heap::waitWhileNeedFinalize):
(JSC::Heap::finalize):
(JSC::Heap::requestCollection):
(JSC::Heap::waitForCollection):
(JSC::Heap::didFinishCollection):
(JSC::Heap::canCollect):
(JSC::Heap::shouldCollectHeuristic):
(JSC::Heap::shouldCollect):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::collectAccordingToDeferGCProbability):
(JSC::Heap::collect): Deleted.
(JSC::Heap::collectWithoutAnySweep): Deleted.
(JSC::Heap::collectImpl): Deleted.
* heap/Heap.h:
(JSC::Heap::ReleaseAccessScope::ReleaseAccessScope):
(JSC::Heap::ReleaseAccessScope::~ReleaseAccessScope):
* heap/HeapInlines.h:
(JSC::Heap::acquireAccess):
(JSC::Heap::releaseAccess):
(JSC::Heap::stopIfNecessary):
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherConservativeRoots):
(JSC::MachineThreads::gatherFromCurrentThread): Deleted.
* heap/MachineStackMarker.h:
* jit/JITWorklist.cpp:
(JSC::JITWorklist::completeAllForVM):
* jit/JITWorklist.h:
* jsc.cpp:
(functionFullGC):
(functionEdenGC):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
(JSC::JSLock::unlock):
(JSC::JSLock::willReleaseLock):
* tools/JSDollarVMPrototype.cpp:
(JSC::JSDollarVMPrototype::edenGC):
Source/WebCore:
No new tests because existing tests cover this.
We now need to be more careful about using JSLock. This fixes some places that were not
holding it. New assertions in the GC are more likely to catch this than before.
* bindings/js/WorkerScriptController.cpp:
(WebCore::WorkerScriptController::WorkerScriptController):
Source/WTF:
This fixes some bugs and adds a few features.
* wtf/Atomics.h: The GC may do work on behalf of the JIT. If it does, the main thread needs to execute a cross-modifying code fence. This is cpuid on x86 and I believe it's isb on ARM. It would have been an isync on PPC and I think that isb is the ARM equivalent.
(WTF::arm_isb):
(WTF::crossModifyingCodeFence):
(WTF::x86_ortop):
(WTF::x86_cpuid):
* wtf/AutomaticThread.cpp: I accidentally had AutomaticThreadCondition inherit from ThreadSafeRefCounted<AutomaticThread> [sic]. This never crashed before because all of our prior AutomaticThreadConditions were immortal.
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h:
* wtf/MainThread.cpp: Need to allow initializeGCThreads() to be called separately because it's now more than just a debugging thing.
(WTF::initializeGCThreads):
Canonical link: https://commits.webkit.org/182065@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@208306 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-11-02 22:01:04 +00:00
|
|
|
bool m_hasUnderlyingThread { false };
|
2021-05-26 16:46:37 +00:00
|
|
|
Condition m_waitCondition;
|
|
|
|
Condition m_isRunningCondition;
|
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Source/JavaScriptCore:
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
Source/WTF:
For a long time now, I've been adding threads to WTF/JSC and each time I do this, I feel
guilty because those threads don't shut down when they are inactive. For example, in bug
163562, I need to add a new GC thread. There will be one of them per VM. This means that a
JSC API client that starts a lot of VMs will have a lot of threads. I don't think that's
good.
A common pattern for all of these threads is that they have some well-defined trigger that
causes them to run. This trigger has a lock, a condition variable, some logic that determines
if there is work to do, and then of course the logic for the thread's actual work. The thread
bodies usually look like this:
void Thingy::runThread()
{
for (;;) {
Work work;
{
LockHolder locker(m_lock);
while (!hasWork())
m_cond.wait(m_lock);
work = takeWork();
}
doWork(work);
}
}
If you look at ParallelHelperPool (the GC's threads) and DFG::Worklist (some of the JIT's
threads), you will see this pattern.
This change adds a new kind of thread, called AutomaticThread, that lets you write threads to
this pattern while getting automatic thread shutdown for free: instead of just waiting on a
condition variable, AutomaticThread will have a timeout that causes the thread to die. The
condition variable associated with AutomaticThread, called AutomaticThreadCondition, is smart
enough to restart any threads that have decided to stop due to inactivity. The inactivity
threshold is current just 1 second.
In this patch I only adopt AutomaticThread for ParallelHelperPool. I plan to adopt it in more
places soon.
* WTF.xcodeproj/project.pbxproj:
* wtf/AutomaticThread.cpp: Added.
(WTF::AutomaticThreadCondition::create):
(WTF::AutomaticThreadCondition::AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::~AutomaticThreadCondition):
(WTF::AutomaticThreadCondition::notifyAll):
(WTF::AutomaticThreadCondition::add):
(WTF::AutomaticThreadCondition::remove):
(WTF::AutomaticThreadCondition::contains):
(WTF::AutomaticThread::AutomaticThread):
(WTF::AutomaticThread::~AutomaticThread):
(WTF::AutomaticThread::join):
(WTF::AutomaticThread::start):
* wtf/AutomaticThread.h: Added.
* wtf/CMakeLists.txt:
* wtf/ParallelHelperPool.cpp:
(WTF::ParallelHelperClient::ParallelHelperClient):
(WTF::ParallelHelperClient::~ParallelHelperClient):
(WTF::ParallelHelperClient::setTask):
(WTF::ParallelHelperClient::finish):
(WTF::ParallelHelperClient::doSomeHelping):
(WTF::ParallelHelperClient::runTask):
(WTF::ParallelHelperPool::ParallelHelperPool):
(WTF::ParallelHelperPool::~ParallelHelperPool):
(WTF::ParallelHelperPool::ensureThreads):
(WTF::ParallelHelperPool::doSomeHelping):
(WTF::ParallelHelperPool::Thread::Thread):
(WTF::ParallelHelperPool::didMakeWorkAvailable):
(WTF::ParallelHelperPool::helperThreadBody): Deleted.
(WTF::ParallelHelperPool::waitForClientWithTask): Deleted.
* wtf/ParallelHelperPool.h:
Canonical link: https://commits.webkit.org/181393@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@207480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-10-18 20:17:10 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace WTF
|
|
|
|
|
|
|
|
using WTF::AutomaticThread;
|
2016-10-19 17:47:30 +00:00
|
|
|
using WTF::AutomaticThreadCondition;
|