Oilpan: move WorkerGlobalScope to oilpan's heap.

Source/core/workers/WorkerThread.cpp

 /*
  * Copyright (C) 2008 Apple Inc. All Rights Reserved.
  *
  * 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
@@ skipping 119 matching lines @@
     m_workerReportingProxy.workerGlobalScopeStarted(m_workerGlobalScope.get());
 
     WorkerScriptController* script = m_workerGlobalScope->script();
     InspectorInstrumentation::willEvaluateWorkerScript(workerGlobalScope(), startMode);
     script->evaluate(ScriptSourceCode(sourceCode, scriptURL));
 
     runEventLoop();
 
     ThreadIdentifier threadID = m_threadID;
 
+#if !ENABLE(OILPAN)
     ASSERT(m_workerGlobalScope->hasOneRef());
+#endif
 
     // The below assignment will destroy the context, which will in turn notify messaging proxy.
     // We cannot let any objects survive past thread exit, because no other thread will run GC or otherwise destroy them.
+    m_workerGlobalScope->detach();
     m_workerGlobalScope = nullptr;
 
     // Cleanup thread heap which causes all objects to be finalized.
     // After this call thread heap must be empty.
     ThreadState::current()->cleanup();

[haraken, 2014/03/03 12:55:50]

One question:

In the non-oilpan world, it was guaranteed that the worker thread is the last
guy who de-references m_workerGlobalScope. In other words, it was guaranteed
that 'm_workerGlobalScope = nullptr' destroys WorkerGlobalScope. Thus it was OK
to clean up the worker thread after calling 'm_workerGlobalScope = nullptr'.

On the other hand, in the oilpan world, it is not guaranteed that
'm_workerGlobalScope = nullptr' destroys WorkerGlobalScope. It's possible that
WorkerGlobalScope's wrapper is still alive at this point. I don't know how it
happens but it actually happened when I moved Events to the heap. Do you think
this is an expected behavior, or a bug we should pursue?

[sof, 2014/03/03 13:14:00]

We do assert for an empty heap at the end of shutting down, so if whoever
referred to the wrapper wasn't in the heap, it'll trigger. Does that address
your concern a bit re: making a potential bug harder to detect?

 
     // Clean up PlatformThreadData before WTF::WTFThreadData goes away!
     PlatformThreadData::current().destroy();
 
     // The thread object may be already destroyed from notification now, don't try to access "this".
     detachThread(threadID);
 
     ThreadState::detach();
 }
 
@@ skipping 89 matching lines @@
 void WorkerThread::releaseFastMallocFreeMemoryInAllThreads()
 {
     MutexLocker lock(threadSetMutex());
     HashSet<WorkerThread*>& threads = workerThreads();
     HashSet<WorkerThread*>::iterator end = threads.end();
     for (HashSet<WorkerThread*>::iterator it = threads.begin(); it != end; ++it)
         (*it)->runLoop().postTask(adoptPtr(new ReleaseFastMallocFreeMemoryTask));
 }
 
 } // namespace WebCore