[Gc] Interesting behavior under heavy I/O load...not sure I can do anything about it.

Boehm, Hans hans.boehm at hp.com
Thu Dec 3 10:59:50 PST 2009

GC_do_blocking() around the fsync() call should do what you want.  It allows you to tell the collector that you are temporarily not touching the heap, and the collector shouldn't bother trying to stop you, usually because you are likely to already be blocked on something else.


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Talbot, George
> Sent: Thursday, December 03, 2009 8:09 AM
> To: gc at linux.hpl.hp.com
> Subject: [Gc] Interesting behavior under heavy I/O load...not 
> sure I can do anything about it.
> Hi all,
> I've got a program that uses the GC that can do pretty heavy 
> I/O (a distributed filesystem daemon), and I just noticed 
> something interesting.  I had a node that was taking quite a 
> while to respond to a keepalive request, so I broke into it 
> with the debugger.
> What I saw was that GC was trying to stop the world and was 
> waiting for the semaphore that tells it that all the other 
> threads are stopped.  All the other threads were stopped, 
> except for one that was waiting in an fsync() call.
> I was kinda surprised to see that GC could possibly be 
> blocked waiting for I/O, but I guess it's not too surprising. 
>  The process will eventually recover when fsync() finishes, 
> then GC finishes, but I have had extreme cases where things 
> time out because of this.
> Is there anything that I could do about this, do you think, 
> short of avoiding fsync(), which I need for consistency 
> purposes?  I.e. is it possible to decouple I/O with GC in 
> this sort of case?
> --
> George T. Talbot
> <gtalbot at locuspharma.com>
> _______________________________________________
> 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