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

Talbot, George Gtalbot at ansarisbio.com
Thu Dec 3 18:16:44 PST 2009


I just tried it and It worked perfectly in my case.  Is this an area that the future C++ standards might get into?

Thanks for the help, it was greatly appreciated, believe me.

--
George T. Talbot
<gtalbot at locuspharma.com>

________________________________________
From: Boehm, Hans [hans.boehm at hp.com]
Sent: Thursday, December 03, 2009 3:11 PM
To: Talbot, George; gc at linux.hpl.hp.com
Subject: RE: [Gc] Interesting behavior under heavy I/O load...not sure I can    do anything about it.

I don't know if these have received a lot of use, so I'm not sure what kind of experience is out there.  I would generally wrap potentially blocking calls for which the GC_do_blocking overhead is likely to be negligible.  GC_do_blocking() has to save the register state on the stack, so that the GC can find pointers corresponding to the callers' frames.  Thus I'd expect costs on the order of hundreds of cycles.  Wrapping something like a lock acquisition is almost certainly a bad idea.  But wrapping something that's likely to do physical IO or the like, or at least involve a context switch, should be fine.

GC performance will improve if threads are found inside GC_do_blocking(), even if they could be stopped with a signal.  Sending the signal is moderately expensive.  Thus it might even make sense for long compute-bound tasks that change no pointers, allocated no memory, and don't have the last pointer to anything inside the function called by GC_do_blocking().  That should also allow the function to keep running during GC.  But that starts to get fairly tricky, and errors are likely to be a real pain to debug.

GC_do_blocking used to have very limited support, only on pthreads.  But I think someone else (Ivan?) fixed that recently.

Hans

> -----Original Message-----
> From: Talbot, George [mailto:Gtalbot at ansarisbio.com]
> Sent: Thursday, December 03, 2009 11:46 AM
> To: Boehm, Hans; gc at linux.hpl.hp.com
> Subject: RE: [Gc] Interesting behavior under heavy I/O
> load...not sure I can do anything about it.
>
> That's fantastic!
>
> The wrappers for that were pretty easy to write.  Do you (or
> anyone else) have any experience with what calls should be
> wrapped this way?
>
> --
> George T. Talbot
> <gtalbot at locuspharma.com>
>
>
> > -----Original Message-----
> > From: gc-bounces at napali.hpl.hp.com
> > [mailto:gc-bounces at napali.hpl.hp.com]
> > On Behalf Of Boehm, Hans
> > Sent: Thursday, December 03, 2009 2:00 PM
> > To: Talbot, George; gc at linux.hpl.hp.com
> > Subject: RE: [Gc] Interesting behavior under heavy I/O
> load...not sure
> > I can do anything about it.
> >
> > 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.
> >
> > Hans
> >
> > > -----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
> > > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> > >
> > _______________________________________________
> > Gc mailing list
> > Gc at linux.hpl.hp.com
> > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>



More information about the Gc mailing list