[GC] Porting boehm-gc to RTEMS for GCJ

Boehm, Hans hans.boehm at hp.com
Wed Jul 13 12:51:21 PDT 2011


> From: Joel Sherrill
> 
> On Wed, Jul 13, 2011 at 9:03 AM, Jie Liu <lj8175 at gmail.com> wrote:
> > Hi,
> >
> > If I don't port "Thread support"[1] for RTEMS operating system while
> > porting GCJ to it, can I run multiple thread which created in Java ?
> 
> RTEMS has the non-POSIX task suspend and resume.  These
> add an additional blocking state to a thread's state.  They are
> very lightweight.  Would these be suitable to implement the following?
> 
> GC_stop_world()
>     Stops all threads which may access the garbage collected heap,
> other than the caller.
> GC_start_world()
>     Restart other threads.
It depends.  Is it possible to retrieve the register state of the suspended threads?  The GC needs these to find the stack pointer, and pointers residing in machine registers.

You may run into other issues with suspend.  The usual problem is that it's possible to suspend a thread that's holding a critical resource needed for the system to function properly.  We've had some issues along these lines with the signal-based approach as well, and you may run into slightly different ones with explicit thread suspension.

> 
> > I ask this question because: if a RTEMS GCJ program with multiple
> > threads but no memory allocation in threads, the program can run
> > successfully. And if has memory allocation in threads, the program
> may
> > fail, e.g. new char[660] PASS but new char[680] and more will FAIL in
> > new thread. The cause of the error is wrong jump address such as
> > 0xFF0720FF or hanging in the program while stack error.
> 
> I personally don't understand the memory layout requirements in
> general terms for GC.
Could you be more specific?

> RTEMS does not have a main so there
> is no main stack.
Presumably there is still a stack associated with the original thread?

> Thread stack sizes are fixed and don't grow.
That doesn't really matter to the collector, since you don't want the collector to trace from parts of the stack region that are not currently in use.  As far as the collector is concerned, it's important to be able to find the "in use" stack regions.

> 
> What is the relationship between the various types of memory?
Stacks and static data are allocated by the allocated by the underlying system, and the collector has to be able to find those regions (GC_register_data_segments, GC_register_dynamic_libraries, GC_push_all_stacks, GC_push_current_stack).  Heap memory is allocated using GET_MEM, and then tracked internally (and portably) by the collector. GET_MEM can be defined in a platform-specific way.

Hans
> Where does it come from?
> 
> > [1]http://www.hpl.hp.com/personal/Hans_Boehm/gc/porting.html
> >
> > Thanks,
> > Jie
> 
> And thanks again.
> 
> --joel sherrill
> 
> _______________________________________________
> 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