Write barrier for G1GC SATB wasn't atomic?
Narihiro Nakamura
authornari at gmail.com
Wed Mar 23 06:11:24 UTC 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