concurrentMarkSweepThread.hpp revision 2212
0N/A * Copyright (c) 2001, 2011, Oracle and/or its affiliates. All rights reserved. 0N/A * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 0N/A * This code is free software; you can redistribute it and/or modify it 0N/A * under the terms of the GNU General Public License version 2 only, as 0N/A * published by the Free Software Foundation. 0N/A * This code is distributed in the hope that it will be useful, but WITHOUT 0N/A * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 0N/A * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 0N/A * version 2 for more details (a copy is included in the LICENSE file that 0N/A * accompanied this code). 0N/A * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any // The Concurrent Mark Sweep GC Thread // CMS thread should yield for a young gen collection, direct allocation, static char _pad_1[
64 -
sizeof(
jint)];
// prevent cache-line sharing static char _pad_2[
64 -
sizeof(
jint)];
// prevent cache-line sharing // Tracing messages, enabled by CMSTraceThreadState. static volatile int _icms_disabled;
// a counter to track #iCMS disable & enable // Returns the CMS Thread // Create and start the CMS Thread, or stop it on shutdown // Synchronization using CMS token // Wait on CMS lock until the next synchronous GC // or given timeout, whichever is earlier. A timeout value // of 0 indicates that there is no upper bound on the wait time. // A concurrent full gc request terminates the wait. // The CMS thread will yield during the work portion of its cycle // only when requested to. Both synchronous and asychronous requests // (1) A synchronous request is used for young gen collections and // for direct allocations. The requesting thread increments // _pending_yields at the beginning of an operation, and decrements // _pending_yields when that operation is completed. // In turn, the CMS thread yields when _pending_yields is positive, // and continues to yield until the value reverts to 0. // (2) An asynchronous request, on the other hand, is used by iCMS // for the stop_icms() operation. A single yield satisfies all of // the outstanding asynch yield requests, of which there may // occasionally be several in close succession. To accomplish // this, an asynch-requesting thread atomically increments both // _pending_yields and _pending_decrements. An asynchr requesting // thread does not wait and "acknowledge" completion of an operation // and deregister the request, like the synchronous version described // above does. In turn, after yielding, the CMS thread decrements both // _pending_yields and _pending_decrements by the value seen in // _pending_decrements before the decrement. // NOTE: The above scheme is isomorphic to having two request counters, // one for async requests and one for sync requests, and for the CMS thread // to check the sum of the two counters to decide whether it should yield // and to clear only the async counter when it yields. However, it turns out // to be more efficient for CMS code to just check a single counter // _pending_yields that holds the sum (of both sync and async requests), and // a second counter _pending_decrements that only holds the async requests, // for greater efficiency, since in a typical CMS run, there are many more // pontential (i.e. static) yield points than there are actual // (i.e. dynamic) yields because of requests, which are few and far between. // Note that, while "_pending_yields >= _pending_decrements" is an invariant, // we cannot easily test that invariant, since the counters are manipulated via // atomic instructions without explicit locking and we cannot read // the two counters atomically together: one suggestion is to // use (for example) 16-bit counters so as to be able to read the // two counters atomically even on 32-bit platforms. Notice that // the second assert in acknowledge_yield_request() below does indeed // check a form of the above invariant, albeit indirectly. // Order important to preserve: _pending_yields >= _pending_decrements static void start_icms();
// notify thread to start a quantum of work static void stop_icms();
// request thread to stop working void icms_wait();
// if asked to stop, wait until notified to start // Incremental mode is enabled globally by the flag CMSIncrementalMode. It // must also be enabled/disabled dynamically to allow foreground collections. // Used to emit a warning in case of unexpectedly excessive // looping (in "apparently endless loops") in CMS code. #
endif // SHARE_VM_GC_IMPLEMENTATION_CONCURRENTMARKSWEEP_CONCURRENTMARKSWEEPTHREAD_HPP