Write barrier for G1GC SATB wasn't atomic?

Narihiro Nakamura authornari at gmail.com
Tue Mar 22 23:11:24 PDT 2011


Hi, all.

I read G1GC by a hobby.
I have one question about write barrier for SATB.

I think that satb write barrier is defined in the following points:
- cpu/sparc/vm/assembler_sparc.cpp: MacroAssembler::g1_write_barrier_pre()
- cpu/x86/vm/assembler_x86.cpp: MacroAssembler::g1_write_barrier_pre()
- share/vm/opto/graphKit.cpp: GraphKit::g1_write_barrier_pre()

I read their code.
I think that the pseudo-cord of "satb write barrier" is as follows:

1: def satb_write_barrier(field, newobj):
2:     oldobj = *field   // (a)
3:     if $gc_phase == GC_CONCURRENT_MARK and oldobj != Null:
4:         enqueue($current_thread.stab_mark_queue, oldobj) // (b)
5:     *field = newobj   // (c)

This code doesn't look like in atomic operation from (a) to (b).
In that case, when mutator more than 2 try to write *field at the
same time, the reference that should record may leak out to satb
mark queue.

For example.
1. *field == obj0 address
2. t1(Thread1) try to write obj1 address to *field.
3. t2(Thread2) try to write obj2 address to *field.
4. t1 at (a): oldobj = obj0
5. t2 at (a): oldobj = obj0
6. t1 at (b): enqueue obj0 to satb mark queue
7. t2 at (b): enqueue obj0 to satb mark queue
8. t1 at (c): *field = obj1
9. t2 at (c): *field = obj2

In this example, obj1 that should enqueue satb mark queue is leaked.

Is this intended behavior? Or, Is it my misunderstanding?

Thanks.
-- 
Narihiro Nakamura (nari)
http://www.narihiro.info/index.en.html


More information about the hotspot-gc-dev mailing list