precise and imprecise card marking?

Tom Rodriguez tom.rodriguez at oracle.com
Mon Apr 4 10:20:35 PDT 2011



tom

On Apr 4, 2011, at 9:54 AM, Y. Srinivas Ramakrishna wrote:

> 
> Sorry for a somewhat naive question, but i have forgotten a few old
> history lessons, which i'll need to relearn...
> 
> As I understand, array objects in hotspot are always precisely marked,
> but non-array objects are sometimes precisely and sometimes imprecisely
> marked. (Is this understanding correct?)

For Java code both the compilers and interpreter always do imprecise marks for regular Java object and precise marks for array.  However, Unsafe operations always do precise card marks because they don't necessarily know whether they are operating on arrays or not.  oop_stores in the C++ source are done as precise card marks.

> 
> I ask because there is some card-scanning code in GC that gets quite
> convoluted on account of the latter (imprecise and precise marking
> of non-array objects), which has recently turned up a(n apparently
> long-standing) bug in parallel card-scanning with ParNew, re 6883834.
> While it is possible to fix this bug assuming the current card-marking
> constraints, I wanted to check what people thought of the (im)possibility
> (or otherwise) of making the JVM always precisely card-mark all
> updates. (This would simplify the code in card-scanning,
> allow us to throw away a bunch of somewhat convoluted code in
> ParNew's parallel card-scanning, and eliminate the bug in 6883834.)
> 
> So, what is the fundamental reason for sometimes marking objects
> imprecisely? Does it make generated code much faster, or ..., or ... ?

The code is much better when doing imprecise marks since you don't have the extra add, shift and store.  Precise card marks also makes elminating redundant card marks hard when updating multiple fields in the same object since they might span a card.  You'd have to do something more clever like keeping the highest and lowest card marks, assuming the offsets are less the card size.  So for a simple example of updating two regular Java fields instead of this:

set cardtable, %i2
st %i0, [%i4 + 12]
st %i1, [%i4 + 16]
sll %i4, 9, %i3
stb %g0 [%i3 + %i2]

you have to do this:

set cardtable, %i2
st %i0, [%i4 + 12]
add %i4, 12, %i3
sll %i3, 9, %i3
stb %g0 [%i3 + %i2]
st %i1, [%i4 + 16]
add %i4, 16, %i3
sll %i3, 9, %i3
stb %g0 [%i3 + %i2]

You could simply always update the next card at the cost of some overscanning.  Anyway, I think imprecise marking for regular Java object would definitely have a performance impact on mutator speed.  It would be easy to do the experiment though if you are interested.  For C2 you can probably just change the handling of the use_precise flag in GraphKit::post_barrier to make it always true.

tom


> 
> thanks!
> -- ramki



More information about the hotspot-dev mailing list