[Gc] Atomicity of GC_get_heap_size

Boehm, Hans hans.boehm at hp.com
Tue Nov 18 11:43:54 PST 2008

Good point.  They should acquire the GC lock.  We should conform to the C++0x rules whenever possible.   That means we should avoid data races whenever possible.

(I know of only one place where it seems we unavoidably have to cheat, and that seems specific to concurrent garbage collectors.  The concurrent marker reads the heap while mutators may be modifiying it.  If there was a concurrent modification,the collector doesn't care what value it got (half of the old and half of the new is OK), but since the value may change asynchronously, it's still violating the compiler's assumptions.  The code should probably highlight those references, since the C compiler is entitled to break that code, though that's extremely unlikely.  We could probably avoid the issue by resorting to assembly code there.)


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Tuesday, November 18, 2008 4:29 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Atomicity of GC_get_heap_size
> Hi!
> Q: Should GC_get_heap_size(), GC_get_free_bytes(),
> GC_get_bytes_since_gc() and GC_get_total_bytes() have some
> sort of locking (at least, on targets where AO_t is not word)?
> Bye.
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list