Re: GC_enable_incremental()

[DHollenbeck <dick at softplc dot com>]

> The real-time thread is running Java code?
>  
Yes

> There are several issues with getting incremental collection to work
> in 3.4:
>
> 1) There is a bug in pthread_support.c which causes the thread stopping
> signal handler to disable signals and the write to a heap object.  This
> is bad if that object is write protected, something that can happen with
> the incremental collector.  Hence the "killed" message.  This should be
> fixed in the CVS trunk.  The fix should probably be backported to 3.4,
> but it hasn't been.  The problem seems to show up only with 2.6 kernels.
>  
Thanks.  I'll see about getting this fix in.  Until we have a valid 
comparison of 1) with and 2) without "incremental" to talk about, little 
can be done in the way of strategizing.   Need a basis of comparison, 
don't have that yet.

> 2) There hasn't been a systematic effort to get incremental GC debugged
> and tested in the context of gcj.  This is nontrivial, since it can break
> if a system call writes to a pointer-containing section of the heap.
> Hence the library has to play by a stricter set of rules.
>  
From experience, I know that your use of "nontrivial" is in itself 
nontrivial  :)

> 3) I'm not sure it would help that much, since most of the GC time
> in your context (tiny heap, I presume?) is probably spent tracing the
> huge root set, and that will still happen with the world stopped.
>  

Have you seen this?

 http://www.aicas.com/papers/rtss99_fsiebert.pdf

> There are plans to fix this, but it hasn't happened.
> I think partial solutions were available a while ago, but I believe
> they're not in the official tree.
>
>  
How do I find these?

> Depending on your tolerance level, Fixing (3) may get the pause time to
> acceptable levels, even without incremental GC.
>
> Other possible solutions you might consider:
>
> - If you know that you have sufficient idle time on a regular basis,
> you can manually invoke the collector early, and abort it if it turns
> out you have something to do.  This should work well for a few
> applications, though perhaps not yours.
>
> - If the real-time thread doesn't need to manipulate the Java heap,
> you might be able to exempt it from suspension by the GC.  There
> is currently no official interface to do this, but it's probably
> not hard.  It's unsafe if the thread allocates or changes pointers
> in the Java heap.
>
>  
Yes, this might be the path of least resistance for my immediate needs.  
A lock or two and the source file you mentioned above.

Long term, I think this project would benefit greatly from an 
incremental [real-time] garbage collector.  I say this because the AHOT 
compilation is largely of benefit to embedded users.  Well, those same 
embedded users cannot tolerate the big GC delays.  So you have a project 
with bells but not whistles. 

A) I wish I could contribute to this effort, but I just don't know that 
I have the time to do that and make a living.  I would be willing to 
donate a realtime GC and answer a bunch of questions on how it works 
though. It uses a modified baker's treadmill algorithm and utilizes 
write barriers.  Of course I do understand that folks are often inclined 
to fix their own code rather than learning new code.  (I find myself on 
that fence right now.)

B) The paper I reference above suggests a technique to avoid the write 
barriers, and suggests that it is single processor only.  (I cannot 
understand why it should be single processor only, other than that only 
one thread runs.)

On the other hand, going back to A), doing the write barriers properly 
will mean putting compile time macros into the Java interpreter and 
teaching the AHOT compiler how to conditionally emit code to make those 
same write barrier calls.

Something probably needs to be done I think.  I find the GC pause to 
severly limit the applicability of this Java runtime.  But then as I 
said, I have not gotten the GC_enable_incremental() to work yet so I 
have no right to pass judgement yet.

Thank you Hans for responding to my questions,

Dick Hollenbeck


> Hans
>
>
>  
>
> > -----Original Message-----
> > From: java-owner@gcc.gnu.org 
> > [mailto:java-owner@gcc.gnu.org]On Behalf Of
> > DHollenbeck
> > Sent: Tuesday, September 07, 2004 1:24 PM
> > To: java@gcc.gnu.org
> > Subject: GC_enable_incremental()
> >
> >
> > My embedded environment:  3.4.1,  pentium 800Mhz, Linux 
> > kernel 2.6.7, 32 
> > mb RAM.
> >
> > The GC when operating without "incremental", is stopping a thread of 
> > mine, one that is elavated to real time policy status, for 57 msecs 
> > every 5 seconds or so.  This is silly putty, not tolerable or useable 
> > for an embedded environment.
> >
> > Then, trying to go incremental GC, when I call 
> > GC_enable_incremental() 
> > the process terminates with a
> >
> > Killed
> >
> > message.  Same is true if I simply set the environment variable 
> > GC_ENABLE_INCREMENTAL=1 before starting the process and do 
> > not call the 
> > function GC_enable_incremental().
> >
> > I've written a realtime incremental garbage collector myself in 1996, 
> > but I have no clue on where or how I could hook it in to 
> > replace the one 
> > in place.  The documentation for that does jump out at me.  Nor do I 
> > have the time to do it, really.  Write barriers, etc.
> >
> > I was hoping to use libgcj, but it seems it may not be up to the task.
> >
> > Please help:
> >
> > ** Has anyone used GC_ENABLE_INCREMENTAL on x86 linux kernel 2.6.x? 
> >
> > ** How else can I get rid of the pause to my realtime thread?  Source 
> > filenames please.
> >
> >
> > Thank you kindly folks,
> >
> > Dick Hollenbeck
> >
> >
> >    
>
>