GCJ port to RTEMS

[Joel Sherrill]

John Neil wrote:

> I recently went looking for a port of libgcj to rtems.  The person mentioned
> on the web pages informed me that he hadn't worked on this for a couple of
> years however the basic posix stuff should work.  Anyway after a little work
> I got this to work with gcc 3.4/ libgcj 3.4 (gcj 3.4 is better than the
> previous versions) and rtems-ss-20030703 (I couldn't get the cvs stuff to
> compile), using the boehm garbage collector.  Currently I only support
> threads and limited diagnostic IO, no network or file io, though these
> should be easy to add.  I didn't use the gcj posix stuff directly, but
> rather provided small wrapper functions in a similar vein to gxx_wrappers.
> Anyway, as part of this effort I have some questions and would appreciate if
> somebody could help.
> 
> One of the reasons I didn't use the gcj posix port directly as it doesn't
> check return codes of things like pthread_mutex_init, as I suspect under
> linux these can never fail.  Unfortunately under rtems these can fail if,
> for example too many mutex's are created.  This is somewhat problematic as
> under gcj a mutex can be created for every object object so it is difficult
> to pre-determine how many are needed.  Currently I set these to a large
> value, however would it be possible to create the mutexes out of "heap
> memory" or are all critical region primitives defined within configuration
> parameters.

In the Classic API, there is a concept of configuring for "unlimited
objects".  That way, the configured limit is actually the number of
that object allocated each time you run out.  So if you configure 10
of something, when you allocate the 11th, it allocates instances 11-20
rather than returning an error.  This continues until you run out of
RTEMS Workspace.

I think it will work for POSIX threads and mutexes but no one has ever
tested it.

Does gjc use POSIX keys?  There is a known limitation with "unlimited
objects" where the existing keys don't get extended.  You could run into
that.

Overall, it could just turn out to be that using gjc with RTEMS
requires some instructions on how to configure RTEMS.  gnat has the
same issue.  You have to know what to turn on in RTEMS to make it
work.

> As part of the boehm gc, it is necessary to scan all thread stacks for
> possible object roots.  Is it possible to get a list of all the threads
> running in a system so that their stacks can be scanned.  I currently
> maintain a list of "Java" Threads and scan these, however this is not a
> general solution and it would be better to scan all threads.  I tried
> various object lists, however these didn't seem to give me what I wanted.
> Further to this, is it possible to get the current SP of the threads within
> the stack, this makes the scanning faster.

In the snapshot tree, there is a new function which might help you
enormously:

typedef void (*rtems_per_thread_routine)( Thread_Control * );

void rtems_iterate_over_all_threads(
   rtems_per_thread_routine routine
);

The current sp of all but the currently executing thread is located
in the Thread_Control structures like this:

   Thread_Control *t;

   t->Register.XXX;

Unfortunately XXX is the port specific register name for the stack
pointer.  Two alternatives -- conditionally compile the function
getting the SP or add to each port a macro for "stack pointer
register name"

> Typically the boehm gc expands its heap size using sbrk, and expansion slots
> are expected to be on a page boundary.  Does rtems have a memory management
> system which allows for the allocation of memory on page boundaries.  I
> suspect that the rtems malloc would be inefficient in terms of space as the
> returned blocks would have to be rounded to boundaries.  I currently
> allocate a block for java heap usage, however does not lead to an efficient
> use of memory.

sbrk() is generally not supported by RTEMS BSPs since all available
memory is given to the application when it starts.  It is a BSP issue
how memory is divided up specifically how much is assigned to the
C program heap and the RTEMS workspace.

I don't understand how the boehm gc is really working so can't say much
more.  How does it interact with C program use of the heap via malloc()?


> I would like to pass segmentation faults to the java thread in error using a
> signal.  I assume that I need an ISR for the illegal address vector, and
> send a signal to the current thread.  Is there a code fragment which does
> this.  If so is this automatically enable for posix APIs 

This sounds like something similar to what GNAT expects.  Check out
c/src/lib/libbsp/sparc/shared/gnatcommon.c and see if that is
about what you have in mind. If so, that mechanism just needs to be
more general than just got gnat and ported to other architectures
since I don't think that currently all ports have this code.

> I am willing to send in these changes if anybody is interested.  How does
> one go about this

You have started correctly.  :)  At some point, you will have to deal
with patches to the gcc source base and RTEMS.  Just keep us abreast and
feed patches in in small pieces so they are easy to comment on.

Ideally, you could keep notes and turn it into a small article on
how the port works.  Some journal would likely publish it but for
sure it would be added to the RTEMS documentation set or website.

> Cheers
> John

--joel


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985