1
0
forked from 0ad/0ad

Tunes GC scheduling a bit to reduce memory usage.

The main problem was that GC was only called from the simulation before
this patch. This means when you were waiting in the multiplayer lobby or
just had the GUI open, it only called GC when getting close to the JS
runtime size limit (I assume). Another problem was the Net Server
runtime which didn't GC either. Here the runtime size limit is 16 MB
though, so it's not too terrible. These issues have both been addressed
and GC has been given a bit more time per incremental slice to make sure
it gets done in time. It's still far from perfect, but there are too
many changes in SpiderMonkey related to GC, so I don't want to spend too
much time on this yet.

Refs #2808

This was SVN commit r15787.
This commit is contained in:
Yves 2014-09-22 20:13:04 +00:00
parent 3f75e5db0e
commit 3b49576fa6
7 changed files with 63 additions and 25 deletions

View File

@ -377,6 +377,10 @@ void CGUIManager::TickObjects()
{
PROFILE3("gui tick");
// We share the script runtime with everything else that runs in the same thread.
// This call makes sure we trigger GC regularly even if the simulation is not running.
m_ScriptInterface->MaybeIncrementalRuntimeGC(1.0f);
// Save an immutable copy so iterators aren't invalidated by tick handlers
PageStackType pageStack = m_PageStack;

View File

@ -391,6 +391,8 @@ bool CNetServerWorker::RunStep()
// (Do as little work as possible while the mutex is held open,
// to avoid performance problems and deadlocks.)
m_ScriptInterface->MaybeIncrementalRuntimeGC(0.5f);
JSContext* cx = m_ScriptInterface->GetContext();
JSAutoRequest rq(cx);

View File

@ -886,8 +886,11 @@ bool Init(const CmdLineArgs& args, int flags)
// (required for finding our output log files).
g_Logger = new CLogger;
// Workaround until Simulation and AI use their own threads and also their own runtimes
g_ScriptRuntime = ScriptInterface::CreateRuntime(384 * 1024 * 1024);
// Using a global object for the runtime is a workaround until Simulation and AI use
// their own threads and also their own runtimes.
const int runtimeSize = 384 * 1024 * 1024;
const int heapGrowthBytesGCTrigger = 20 * 1024 * 1024;
g_ScriptRuntime = ScriptInterface::CreateRuntime(runtimeSize, heapGrowthBytesGCTrigger);
// Special command-line mode to dump the entity schemas instead of running the game.
// (This must be done after loading VFS etc, but should be done before wasting time

View File

@ -132,7 +132,10 @@ void CReplayPlayer::Replay(bool serializationtest)
new CProfileManager;
g_ScriptStatsTable = new CScriptStatsTable;
g_ProfileViewer.AddRootTable(g_ScriptStatsTable);
g_ScriptRuntime = ScriptInterface::CreateRuntime(384 * 1024 * 1024);
const int runtimeSize = 384 * 1024 * 1024;
const int heapGrowthBytesGCTrigger = 20 * 1024 * 1024;
g_ScriptRuntime = ScriptInterface::CreateRuntime(runtimeSize, heapGrowthBytesGCTrigger);
CGame game(true);
g_Game = &game;

View File

@ -135,9 +135,11 @@ void GCSliceCallbackHook(JSRuntime* UNUSED(rt), JS::GCProgress progress, const J
class ScriptRuntime
{
public:
ScriptRuntime(int runtimeSize):
ScriptRuntime(int runtimeSize, int heapGrowthBytesGCTrigger):
m_rooter(NULL),
m_LastGCBytes(0)
m_LastGCBytes(0),
m_LastGCCheck(0.0f),
m_HeapGrowthBytesGCTrigger(heapGrowthBytesGCTrigger)
{
m_rt = JS_NewRuntime(runtimeSize, JS_USE_HELPER_THREADS);
@ -175,9 +177,10 @@ public:
ENSURE(m_dummyContext);
}
void MaybeIncrementalGC()
void MaybeIncrementalGC(double delay)
{
PROFILE3("MaybeIncrementalGC");
PROFILE2("MaybeIncrementalGC");
if (JS::IsIncrementalGCEnabled(m_rt))
{
// The idea is to get the heap size after a completed GC and trigger the next GC when the heap size has
@ -185,8 +188,20 @@ public:
// In practice it doesn't quite work like that. When the incremental marking is completed, the sweeping kicks in.
// The sweeping actually frees memory and it does this in a background thread (if JS_USE_HELPER_THREADS is set).
// While the sweeping is happening we already run scripts again and produce new garbage.
const int GCSliceTimeBudget = 30; // Milliseconds an incremental slice is allowed to run
// Have a minimum time in seconds to wait between GC slices and before starting a new GC to distribute the GC
// load and to hopefully make it unnoticeable for the player. This value should be high enough to distribute
// the load well enough and low enough to make sure we don't run out of memory before we can start with the
// sweeping.
if (timer_Time() - m_LastGCCheck < delay)
return;
m_LastGCCheck = timer_Time();
int gcBytes = JS_GetGCParameter(m_rt, JSGC_BYTES);
//printf("gcBytes: %d \n", gcBytes);
//std::cout << "gcBytes: " << std::endl; // debugging
if (m_LastGCBytes > gcBytes || m_LastGCBytes == 0)
{
//printf("Setting m_LastGCBytes: %d \n", gcBytes); // debugging
@ -196,16 +211,20 @@ public:
// Run an additional incremental GC slice if the currently running incremental GC isn't over yet
// ... or
// start a new incremental GC if the JS heap size has grown enough for a GC to make sense
if (JS::IsIncrementalGCInProgress(m_rt) || (gcBytes - m_LastGCBytes > 20 * 1024 * 1024))
if (JS::IsIncrementalGCInProgress(m_rt) || (gcBytes - m_LastGCBytes > m_HeapGrowthBytesGCTrigger))
{
/* Use for debugging
if (JS::IsIncrementalGCInProgress(m_rt))
printf("Running incremental garbage collection because an incremental cycle is in progress. \n");
// Use for debugging
/*if (JS::IsIncrementalGCInProgress(m_rt))
printf("Running incremental GC because an incremental cycle is in progress. \n");
else
printf("Running incremental garbage collection because JSGC_BYTES - m_LastGCBytes > X ---- JSGC_BYTES: %d m_LastGCBytes: %d", gcBytes, m_LastGCBytes);
*/
printf("Running incremental GC because JSGC_BYTES - m_LastGCBytes > m_HeapGrowthBytesGCTrigger "
" ---- JSGC_BYTES: %d m_LastGCBytes: %d m_HeapGrowthBytesGCTrigger: %d ",
gcBytes,
m_LastGCBytes,
m_HeapGrowthBytesGCTrigger);
}*/
PrepareContextsForIncrementalGC();
JS::IncrementalGC(m_rt, JS::gcreason::REFRESH_FRAME, 10);
JS::IncrementalGC(m_rt, JS::gcreason::REFRESH_FRAME, GCSliceTimeBudget);
m_LastGCBytes = gcBytes;
}
}
@ -236,7 +255,9 @@ private:
// Workaround for: https://bugzilla.mozilla.org/show_bug.cgi?id=890243
JSContext* m_dummyContext;
int m_HeapGrowthBytesGCTrigger;
int m_LastGCBytes;
double m_LastGCCheck;
void PrepareContextsForIncrementalGC()
{
@ -374,9 +395,9 @@ private:
}
};
shared_ptr<ScriptRuntime> ScriptInterface::CreateRuntime(int runtimeSize)
shared_ptr<ScriptRuntime> ScriptInterface::CreateRuntime(int runtimeSize, int heapGrowthBytesGCTrigger)
{
return shared_ptr<ScriptRuntime>(new ScriptRuntime(runtimeSize));
return shared_ptr<ScriptRuntime>(new ScriptRuntime(runtimeSize, heapGrowthBytesGCTrigger));
}
////////////////////////////////////////////////////////////////
@ -1398,9 +1419,9 @@ void ScriptInterface::DumpHeap()
fprintf(stderr, "# Bytes allocated after GC: %u\n", JS_GetGCParameter(GetJSRuntime(), JSGC_BYTES));
}
void ScriptInterface::MaybeIncrementalRuntimeGC()
void ScriptInterface::MaybeIncrementalRuntimeGC(double delay)
{
m->m_runtime->MaybeIncrementalGC();
m->m_runtime->MaybeIncrementalGC(delay);
}
void ScriptInterface::MaybeGC()

View File

@ -59,6 +59,7 @@ class AutoGCRooter;
// TODO: what's a good default?
#define DEFAULT_RUNTIME_SIZE 16 * 1024 * 1024
#define DEFAULT_HEAP_GROWTH_BYTES_GCTRIGGER 2 * 1024 *1024
struct ScriptInterface_impl;
@ -89,7 +90,8 @@ public:
* Each runtime should only ever be used on a single thread.
* @param runtimeSize Maximum size in bytes of the new runtime
*/
static shared_ptr<ScriptRuntime> CreateRuntime(int runtimeSize = DEFAULT_RUNTIME_SIZE);
static shared_ptr<ScriptRuntime> CreateRuntime(int runtimeSize = DEFAULT_RUNTIME_SIZE,
int heapGrowthBytesGCTrigger = DEFAULT_HEAP_GROWTH_BYTES_GCTRIGGER);
/**
@ -354,10 +356,12 @@ public:
* be worth the amount of time it would take. It does this with our own logic and NOT some predefined JSAPI logic because
* such functionality currently isn't available out of the box.
* It does incremental GC which means it will collect one slice each time it's called until the garbage collection is done.
* This can and should be called quite regularly. It shouldn't cost much performance because it tries to run a GC only if
* necessary.
* This can and should be called quite regularly. The delay parameter allows you to specify a minimum time since the last GC
* in seconds (the delay should be a fraction of a second in most cases though).
* It will only start a new incremental GC or another GC slice if this time is exceeded. The user of this function is
* responsible for ensuring that GC can run with a small enough delay to get done with the work.
*/
void MaybeIncrementalRuntimeGC();
void MaybeIncrementalRuntimeGC(double delay);
/**
* Triggers a full non-incremental garbage collection immediately. That should only be required in special cases and normally

View File

@ -449,10 +449,11 @@ void CSimulation2Impl::Update(int turnLength, const std::vector<SimulationComman
// m_ComponentManager.GetScriptInterface().DumpHeap();
// Run the GC occasionally
// No delay because a lot of garbage accumulates in one turn and in non-visual replays there are
// much more turns in the same time than in normal games.
// (TODO: we ought to schedule this for a frame where we're not
// running the sim update, to spread the load)
if (m_TurnNumber % 1 == 0)
m_ComponentManager.GetScriptInterface().MaybeIncrementalRuntimeGC();
m_ComponentManager.GetScriptInterface().MaybeIncrementalRuntimeGC(0.0f);
if (m_EnableOOSLog)
DumpState();