[GC] Porting boehm-gc to RTEMS for GCJ

Joel Sherrill joel.sherrill at gmail.com
Wed Jul 13 13:53:07 PDT 2011

On Wed, Jul 13, 2011 at 2:51 PM, Boehm, Hans <hans.boehm at hp.com> wrote:
>> 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.

The method of blocking is independent of the answer to this question.

Yes easily to stack pointer.

Other pointers is a bit more complicated.  The RTEMS thread context
area only contains registers which are preserved across subroutine
calls.  So on x86, it does not contain eax, ecx and edx.  Context switch
is a subroutine call and caller can assume those are clobbered.

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

OK.  Then the port should stick with the standard POSIX way
of doing things.  That code is well tested anyway which does
have its advantages. :)

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

How many areas of memory does GC manage?  Special management
on top of malloc()? Allocation from stack like alloca()?

RTEMS is logically a single process in an unprotected flat address space
with multiple threads.  Without VM, it is important to understand where
things physically are located.

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

Yes.  As long as it doesn't exit.

Any guidance on sizing what we refer to as the initialization task's
stack?  I know for C it can usually be fairly small for many applications
but for Ada it can need to be many times larger.  What factors go
into determining the maximum size to reserve?

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

OK.  I think that is doable since you can easily get to the stack
of any thread.

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

By static data, you mean the .data and .sdata segments?

And stacks are obviously known by threading system.

Sorry to ask such fundamental questions GC has a lot of target architectures
and RTEMS has even more.  I want to make sure we are making decisions
that are very broad so the next architecture supported is easy.  And when
something is broken in the RTEMS port, I have a clue as to what might be

Just give us pointers and we will get there. :)



> Hans
>> Where does it come from?
>> > [1]https://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
>> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list