GC of STW type does not collect the garbage while executing the program, memory is depleted, becoming, starting, it is the GC system which enters into the collection mode of the garbage. With this system, ��the time that stop��, because everything of the program is made to stop, the concept of ��the down time due to GC�� exists.

on the one hand, On-the-fly type GC can do execution of the program (allotment of the object which is included) with the collection of the garbage completely in parallel. Because there are no times when it enters into special mode in order to collect the garbage ��the stop with GC�� cannot occur, or almost can ignore.

as for On-the-fly type GC there is no stop with GC, response efficiency is very good. But, as for the actual GC algorithm which actualizes On-the-fly type GC throughput efficiency (operation of the time) low ones are many with especially multithread operation, the unique weak point (the object which has the reference which circulates mutually cannot be collected) have in addition depending upon algorithm.

on the one hand, as for STW type GC it is necessary to put ��the down time due to GC��, but is, the cost which catches when GC is not executed can be lower than On-the-fly type GC, raise throughput efficiency. So far because among the fields where Java language participates ray ten sea efficiency compared to there was many a thing where throughput efficiency is required, the majority of past JavaVM adopted STW type GC.

, in the recent Java system it is it reaching the point where again [reitenshi] efficiency is seriously considered. You can use, it has increased the memory quantity which uses JavaVM attendant upon low price large increasing capacity of memory and the spread of 64 bit processor. Many of STW type GC algorithm because the memory quantity which GC has managed, the quantity of the object which has existed, it is proportionate to either of the numbers of references of the object which has existed, is a tendency where GC down time extends steadily. When the kind of memory which exceeds the gigabyte is used, the kind of pattern where the down time due to GC exceeds 10 seconds it has appeared.

because of that, the GC kind of algorithm which is compatible throughput efficiency and [reitenshi] efficiency becomes necessary. Below, Mostly where you express in this page Concurrent GC is the GC system like the child of the meeting of STW type and On-the-fly type.

2. The type of GC of HotSpot VM 1.4.x

JavaVM of Java2SE JDK of Sun was mounted, the plural garbage collections (GC) algorithm was designed in such a way that it is changed according to the quality of application.

GC type	Option	Tendency proper	Explanation
Normal	Unspecified	Basis	The classified by generation who combines Copying GC and Mark & Compact (Generational) GC. This becomes the basis.
Parallel GC	- XX: +UseParallelGC	For server multiple CPU Throughput concern	But normal the classified by generation GC who is similar, those which replace Copying GC of new generation side to Parallel Copying GC . Minor GC (1 processing times are short, occurrence frequency multi), Major GC (1 processing times are long, the time when the occurrence frequency small) inside Minor GC stops JavaVM is shortened and execution efficiency improves. However because there is no improvement in Major GC, you do not improve the worst value of the response time.
Concurrent GC	- Xconcgc	For server multiple CPU Response concern	But classified by generation GC, old generation side those which replace Mostly-concurrent Mark & Sweep algorithm. Because the time when Major GC stops JavaVM is shortened, the worst value of the response time can be improved. Additional option - XX: By the fact that it appoints +UseParNew , - XX: +UseParallelGC it can also use the parallel GC which is similar. In this case, also throughput efficiency is improved. Here the concurrent (Concurrent) with as for the word which is said it is synonymous, On-the-fly.
Incremental GC	- Xincgc	For client Response concern	Incremental GC which uses Train GC algorithm. The application whose memory size is small only with GC which works effectively, with this kind of application the down time of 1 GC can be shortened dramatically (below 64MB). However, throughput decreases. When memory size was increased, throughput and the response decrease.

3. Mostly-concurrent Mark & Sweep

The concurrent GC which HotSpot VM 1.4.x adopts is Mostly-concurrent Mark & Sweep .

As for this algorithm, Hans-J. Boehm and Alan J. 3 people of Demers and Scott Shenker announced [1] Mostly Parallel Garbage Collection (PLDI 1991) improved Tony Printezis and David Detlefs to the base [2] A Generational Mostly-concurrent Garbage Collection (ISMM 2000) are substantially in 1991. Later and M-CMS we have decided to abbreviate.

As for Mark & Sweep algorithm, when the program memory using up, when the thread which executes the program (it is JavaVM, the Java thread) making stop at one time, 1. 2. The face is executed in order.

1. Mark phase (Mark phase): Hauling at a time 1 pointers inside the object which ��has lived,�� the phase which it goes around and in object the mark (mark) it does. Processing of the mark completing entirely, when there not to be an object which it should mark, the object where the mark has not been attached becomes the rubbish (garbage) with.
2. Sweep phase (Sweep phase): The space from the first is scanned lastly in order and the phase which searches the rubbish where the mark has not been attached. As for the rubbish you collect by the fact that it can connect to the free list as an empty territory. Approximately it does also the processing which connects the empty territory together.

Concurrent marking

As for M-CMS Mark & Sweep aiming for the fact that the time when JavaVM stops the program is reduced, 1. Mark phase is improved. Previous GC ending, when the Java thread is reopened, simultaneously, the special marking thread which does marking processing in parallel, it executes M-CMS.

In other words, (1), (2), (3) and (4) object had lived at the point in time when GC ends, if is, the marking thread does as from Root (1) -> (2) -> (3) said to order, the marking. Also the Java thread becoming independent, because it is moving, before if the marking thread does mark processing, (3) -> (4) reference is separated, (4) is not done and the marking becomes the garbage.

The route (root) GC such as the object which points directly from the Java thread and the object which is registered to the system ��you have lived��, that it is the object which is supposed.

Problematical point of concurrent marking

(A) a mark leak: When another object is linked to the object which is marked once, a mark leak occurs.
For example (5) was formed anew, we assume that this was linked in (1). Because (1) already is the mark being completed, (1) -> (5) link cannot be traced.
(B) excessive mark: By the fact that the object which is marked once is separated from the pass from Root, there is a possibility of becoming rubbish object.
For example (3) marked (2) -> while link being (3), the mark thread, but is, the Java thread cut link and truth became the rubbish, (the *1 ).

Automatically translated text:

Among two problems (B) as for the excessive mark it is possible to ignore. When the object which becomes the rubbish ��you have lived��, that it is regarded GC the quantity of the object which survives increasing wastefully, memory is pressed, but if the other rubbish can be collected sufficiently, there is no problem in operation itself of the program. With M-CMS you do not collect the object which is marked in excess.

On the one hand, (A) a mark leak is not permitted under any condition. When there is a mark leak object, that mistaking with the next sweep phase, it is collected, becomes cause of fatal bug.

Light/write barrier (write barrier)

M-CMS copes in this mark leak like below.
First, as for the GC thread ��from Root reachable whether or not�� in order to check the mark was done in object, but separately from this sign of another type is acquired in order to check ��the object which is rewritten��. For example, when like below the thread which executes the Java program, reference of a some object is written to the field of object1 , ��it was written��, the sign that is acquired in object1 . This processing is called the light/write barrier (write barrier) with.
When object2 is not null, it checks with any object.

 void method (Class1 object and Class2 object2) {
object1.field
 = object2; }

It becomes as in the figure under the light/write barrier after being done, as an image in memory.

After-treatment of concurrent marking

M-CMS was done ��concurrently�� in order to cope with a mark leak of the marking processing which, like usual Mark & Sweep stops JavaVM. And it is in heap memory, it keeps doing ��the object empty remaining marking processing which is rewritten midway��.

When it is the figure, (1), (2) and (3) becomes the start point of the marking, (5) it was leaking to the mark is discovered.

This way M-CMS marking processing, in parallel (the concurrent) the part where it does divides into the part which the mark (the serial) is done one by one.

Sweeping phase (Sweeping Phase)

The object which has become the garbage in the heap space which the mark ends is removed and the operation of making the free list is sweeping (Sweeping) with. As for Sweeping it is normal to include Coalescing which connects the empty territory which is continued.
To do concurrently it is possible this operation but is, for lightening the lock operation with Sun HotSpot VM 1.4.x the expectation which has not gone concurrently.

(Postscript)
M-CMS after the Sun HotSpot 1.4.2 has gone sweeping phase concurrently. \

4.1 Combination with classified by generation GC

The dissertation of Printezis and others [ with 1] , you aim for the improvement of efficiency by the fact that M-CMS and classified by generation GC are combined. In this case, of new generation side GC Copying GC of Cheney style, M-CMS is used for the measure GC of old generation side minor.

As for Copying GC of minor GC side in order to do STW, GC down time exists. Simply thinking, that it is stop of the range where the down time of minor GC is short generally, in regard to use does not become inconvenient it allows this.

M-CMS of measure GC side like below obtains the merit by dividing the generation.

As for object of the new generation life to be short renewal frequency is high generally. Life rewrites the object of the old generation conversely long and frequency is low. When M-CMS is squeezed on old generation side, the new generation compared to the light/write barrier with the expectation where the object which is processed decreases, stopping JavaVM, is possible the fact that it decreases the quantity which the marking it does to the serial.
Including the time when minor GC is moving, you can use as the time when it advances the concurrent marking processing of M-CMS side.

It is difficult simply to take the balance of mounting and speed.

4.2 Card marking (Card Marking)

In addition the dissertation of Printezis and others [ with 1] , the card marking (Card Marking) you have used for light/write barrier processing.

This is not to manage the object which has rewriting at the object unit, the heap space is divided fixed size (in dissertation 512 bytes) and manages (this the card). When it can rewrite the object inside the card, it is the system which all objects inside the card judge as rewriting. Object inside the card ��it became dirty, whether or not (it was rewritten)��, it is managed with the private table which is outside the heap space.

As for this you are moved by rough method, but because in regard to the mounting JavaVM the header of object is 2 words, there is no room which stuffs various items of information.

Light/write barrier processing like below becomes the cord/code. When executing the byte cord/code order of putfield, putstatic and aastore etc, it does together.

 #define CARD_SIZE 512 #define DIRTY_MASK ((unsigned char) - 1)/* card table * unsigned char card_marking_table [CARD_SIZE]; void write_barrier (Object* object) {int offset = ((intptr_t) object)/CARD_SIZE; card_marking_table = DIRTY_MASK; }

To show clean or dirty vis-a-vis each card, it is possible to be 1 bits, but is, as for light/write barrier processing because it is done in parallel from the plural Java threads, in bit operation atomic (atomic) order becomes necessary. When that happens, the execution efficiency with multiple CPU becoming the abnormal play falling, it is topsy-turvydom. When unsigned char (8 bits) it consists, just a little wastefully the way, you can think, but because with most CPU reading and writing of 1 bytes becomes inseparable, atomic order and lock operation become unnecessary. In addition when acceleration of the GC algorithm of M-CMS is done, because give the plural parameters it stops wanting vis-a-vis one card there being a width a little, exactly, it is good.

4.3 Parallel conversion (Parallel GC)

Parallel GC (Parallel GC), allotting GC with the plural GC threads, it is the GC system which processes. Every single in case of M-CMS there are concurrent marking phase, serial marking phase and sweep phase three phases, but it is possible to convert each one in parallel.

Because Serial marking phase after making all Java threads stop, is the STW processing which is done, starting the GC thread of the same number as the quantity of CPU theoretically, if it decentralizes load, processing time becomes smallest, (the *2 ). That way it becomes minimization of GC down time and largest conversion of efficiency for processing time of Serial marking phase to become smallest.

On the one hand, as for concurrent marking phase and sweep phase because it is operational parallel with the Java thread, in order progress of the Java program and the progress of GC to become balance good, it is necessary to convert in parallel. In order basic for the speed where speed and the GC thread side where Java thread side consumes memory collect memory generally to become same, the number of GC threads which operate in parallel is adjusted.

4.4 sweep (Bitwise Sweep)

Although the marking flag of position and the object where object exists is displayed, there is a method of preparing bit map outside the heap space. When we assume, that object has lined up into 8 byte boundary in the heap space, if bit map of 1/64 of heap spatial size is prepared, the heap space can be thoroughly contained.

The bit map 2 below is prepared.

Instead of the marking doing the tag bit in object header, preparing the bit map for the marking of 1/64 of heap spatial size, it strikes the bit.
Preparing the alocate bit map of 1/64 of heap spatial size, it strikes the bit which undertakes the start position the occasion where alocate it does object.

It is possible to discover the position of the garbage by the fact that the bit map 2 is referred to the case of Sweep phase, to collect. Rather than licking the heap space, the person who refers to small bit map efficiency is much good.

However when bit map we assume that the thread which operates parallel parallel writes in simultaneously note becomes necessary. For the plural threads bit operation, atomic order is necessary. In order to lighten this, several it optimizes.

If the processor word territory with respect to allocation bit map (they are 32 bits CPU, 4 bytes) the heap space which corresponds is allotted the thread locally. For example when 32 bits CPU are used, 256 byte boundary it pulls hypothetically in the heap space. When the Java thread allots object, it is not to allot to the heap space directly, it guarantees the fixed territory which if parallels to the boundary of 256 bytes among those keeps allotting object, as the thread local buffer and as for the territory of processor word amount with respect to allocation bit bit map there are no times when it is written from the other thread.
Furthermore when you say, there is also a problem of cash line. By the processor because the territory is handled in 32, 64 and 128 byte boundary, as the identical cash line in order for cash line of allocation bit map there is no rose [ke], if it can designate the aforementioned thread local buffer as 2K, 4K and 8K, it is efficient.
When the parallel marking is done with the plural threads, marking bit map without atomic operation it is difficult to rewrite. By the fact that the marking range is divided into every GC thread, reduction of cash mistake is possible.

4.5 Incremental compaction (Incremental Compaction)

Because Mark & Sweep which include M-CMS leaving the object which has lived, keep releasing the object which has become the garbage, the space which is released (the free space) it does not become the space which is continued, the heap space keeps becoming pitted contact point state. It is fragmentation conversion. In order to evade this, shifting the position of the object which has lived, operation and the compaction which you move aside to one place (Compaction) becomes necessary.

Representation of compaction type GC with Mark & Compact, is something which replaces sweep phase of Mark & Sweep to compaction phase. Simply from the Java thread and it can process sweep concurrently, different, as for the compaction after from first making to last Java stop VM unless it does, useless. It depends on also the related characteristic of reference of object, but if only because as for marking phase and compaction phase the same time is required generally, marking became concurrent, GC down time it becomes half. Now excessively there is no effect.

[3] So Incremental Compaction which is proposed is the developmental system of M-CMS. The whole heap to abandon the compaction, in portion of the heap space the window for the compaction ( Evacuated Area; It does to the thing which is called EA ) it provides. The part other than the window sweeps with M-CMS, object inside the window does the compaction which is lined up to one side. The garbage being many in the window, the object which has lived uninformed by the fact that the space is chosen, can expand the free territory which is continued.

Being the window of portion of the proverb heap, when it will move the object which among those is it does, it is necessary to rewrite all pointers which point to the object which we would like to move. Remembering set (Remember Set) it uses in order to advance the movement of this object. As for remembering set you should have thought that it is the arrangement which records the pointer which points to EA.

The EA territory is set before M-CMS + Incremental Compaction starts, remembering set is kept in state of the sky.
When the GC thread which advances marking processing, finds the fact that object outside EA points to the object inside EA, the pointer of object outside EA is added to remembering set.
In order for object outside EA to point to the object inside EA the Java thread with putfield, putstatic and aastore order, you watch, add to remembering set whether or not it is rewritten.

When Serial marking phase and Sweep phase complete, address of the object which refers to the EA territory from outside has entered entirely in remembering set. When it does, the area of influence is limited the compaction of object inside EA to the object which is recorded to remembering set. Targeting just the object which remembering set records it is possible to prevent the speed decrease with the compaction by rewriting portable address.

Incremental Compaction is mounted after the IBM JVM 1.4.2.