Re[2]: [Gc] Interesting behavior under heavy I/O load...not sure I cando anything about it.

Ivan Maidanski ivmai at mail.ru
Fri Dec 4 01:22:26 PST 2009


Hi!
"Talbot, George" <Gtalbot at locuspharma.com> wrote:
> 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.
> ________________________________________
> 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.

Yes, it now working on Win32 (and on Darwin, though I've not tried on it).
There's also the anti-do_blocking() (this works similar to Java model: java code may call native code, the latter is allowed to call java one, and so far).
The areas in stack between each do_blocking and call_with_gc_active pair are not scanned.

>
> 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?

I think the opposite - the wrappers are hard to write in C/C++ (if having a lot of places to be wrapped).

I'd prefer macros, something like:

 ... // some vars defined
 DO_BLOCKING
    ... // some non-pointer vars used
 END_DO_BLOCKING

This was possible with some older GC versions (which have broken (by design) do_blocking implementation). Unfortunately, I don't think macros-based do_blocking construction ever possible in C (contrary to Java 2).

> >
> > --
> > 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 keep alive 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>

Bye.


More information about the Gc mailing list