This patch refactors the following collection operations into SafepointTasks: GC::StartIncrementalMark GC::IncrementalMark GC::Collect GC::FinishIncrementalMark GC::ReapZCT GC-owner threads are permitted to perform any of these tasks. VM-threads may only perform StartIncrementalMark and IncrementalMark as they do not demand thread-affinity of the GC-owner thread. Using 'FinishIncrementalMark' as an example, the refactoring takes the following general form: - FinishIncrementalMark is split into two methods, RequestFinishIncrementalMark and DoFinishIncrementalMark. - DoFinishIncrementalMark contains the original method body of FinishIncrementalMark, with an added assert that the calling thread is a valid collector (see GC::CurrentThreadValidAsCollector()). In typical use, DoFinishIncrementalMark may only be called by a SafepointTask. - RequestFinishIncrementalMark wraps a request to the GC's SafepointManager to dispatch a GCSafepointTask_IncrementalMark runnable object when all of the GC's mutators are safepointed. The GCSafepointTask_IncrementalMark object then calls DoFinishIncrementalMark. As GC::Collect and GC::ReapZCT are public APIs, the original methods are left in place, but simply call GC::RequestCollect and GC::RequestReapZCT respectively. Safepointing protocol demands that any thread running a SafepointTask must acquire all of the locks it will need for the task before requesting the safepoint. In the case of the collection tasks above, the only lock that we need is GC::m_coarseLock. The 'Request' version of the methods above assert that this lock is held by the calling thread before requesting the SafepointTask on the SafepointManager.

(In reply to comment #0) > As GC::Collect and GC::ReapZCT are public APIs, the original methods are left > in place, but simply call GC::RequestCollect and GC::RequestReapZCT > respectively. In fact, StartIncrementalMark, FinishIncrementalMark and IncrementalMark are public APIs too. So they have also been refactored to simply call their respective 'Request' version.

(In reply to comment #1) > (In reply to comment #0) > > As GC::Collect and GC::ReapZCT are public APIs, the original methods are left > > in place, but simply call GC::RequestCollect and GC::RequestReapZCT > > respectively. > > In fact, StartIncrementalMark, FinishIncrementalMark and IncrementalMark are > public APIs too. That seems like a bug waiting to happen, depending a little on what you mean by "public".

(In reply to comment #2) > That seems like a bug waiting to happen, depending a little on what you mean by > "public". IncrementalMark is 'public' in the C++ sense. StartIncrementalMark and FinishIncrementalMark are private in the C++ sense, but 'public' as legacy selftests assume they can use them. I've already fixed up some legacy selftests to avoid asserting in AsymmGC. They could also be changed to use the 'Request' versions of these methods.

Gosh, I'm pretty sure these should all be 'private' in the C++ sense; selftests could be provided with more appropriate APIs or be friended, in a pinch.

Comment on attachment 515822 [details] [diff] [review] MQ rev 250 See http://asteam/hg/users/siwilkin/asymmGC-01 for an asymmGC patch queue qfinished at rev 250 (against TR rev 5916). See http://asteam.corp.adobe.com/hg/users/fklockii/tr-patch-queues for the current queue

Comment on attachment 515822 [details] [diff] [review] MQ rev 250 No red flags here.

Retargeting to Dolores.

Tamarin is a dead project now. Mass WONTFIX.

Tamarin isn't maintained anymore. WONTFIX remaining bugs.