New threads and GC (Was: Re: Mismatched _Thread_Enable_dispatch and _Thread_Disable_dispatch)

[Charles-Antoine Gauthier]

Joel Sherrill wrote:
> 
> Charles-Antoine Gauthier wrote:
> >
> > In
> >
> > rtems/c/src/exec/score/src/objectget.c(_Objects_Get) and
> > rtems/c/src/exec/score/src/objectgetbyindex.c(_Objects_Get_by_index),
> > there is no matching _Thread_Enable_dispatch() to the
> > _Thread_Disable_dispatch() when an object pointer is returned.
> >
> > I am thinking that this might be a explicit design decision rather than
> > an oversight and that you intended the caller to re-enable dispatching.
> > In this way, the caller is guaranteed that the returned pointer points
> > to an existing object until the caller re-enables dispatching (or
> > deletes the object itself). Unfortunately, this is not documented.
> >
> > Was that the intent or is this a bug? I wont "fix it" if the code is
> > "correct", I will just add the _Thread_Enable_dispatch() in the right
> > places.
> 
> It is a VERY deliberate design decision.  When _Objects_Get* returns
> an object pointer, you are ensured that dispatching is disabled.
> If you look at RTEMS services, you will generally see this pattern:
> 
>   error check parameters
> 
>   the_XXX = _XXX_Get( id, &location ); /* wrapper for _Objects_Get */
>   switch ( location ) {
> 
>     case OBJECTS_REMOTE:
>       make remote call
> 
>     case OBJECTS_ERROR:
>       return invalid id error
> 
>     case OBJECTS_LOCAL:
> 
>       any error checks that require the_XXX object pointer to make
> 
>       do operation on the_XXX object.
> 
>       _Thread_Enable_dispatch();
>       return successful status
>   }
> 
> > I found out about this issue the hard way. I attempted to use
> > _Object_Get_by_index() to get the object id of ITRON tasks given only
> > their index. I looked up three tasks and ended up in my main task with
> > _Thread_Dispatch_disable_level set to 3!
> 
> :) And that totally hosed the system I am sure. :)
> 
> > I then looked for all threads (of all types) using _Object_Get_next().
> > That got me into trouble also. (I will try using
> > rtems_monitor_manager_next() directly rather than roll my own now that I
> > found out that this function exists).
> 
> Good idea.
> 
> > The point of the exercise is to push all thread stacks onto the marking
> > stack of the Boehm Garbage Collector. To do this, we need to find all
> > threads, and then find their stacks and stack pointers. As you can see,
> > we are trying to get the last bit of the gcj/libgcj technology ported to
> > RTEMS.
> 
> I think there is a loop in the monitor code to cycle over all tasks.
> Definitely there is one in the usage report generator in the stack
> checker.
> 
> What about a "create" user extension that marks the stack?  Don't you
> need to mark new tasks as well?

Darlene and I both understand that the Boehm collector pushes its root
onto a marking stack at the beginning of each collection cycle (we will
address incremental collection later when we understand and make the
conventional one work properly). Some roots get recorded when they are
created and are pushed at the appropriate times. This is the case with
the .data section, the heap blocks allocated by the collector, and some
other internal data structures. It is not the case with thread stacks.
These have to be pushed explicitly.

Initially, I was going to do exactly what you describe: add an extension
to call GC_add_root to add the stacks when threads are created. But I
quickly realized that my understanding was lacking when I could not find
a matching GC_remove_root! What then to do when a thread is deleted? The
approach taken by Boehm allows the collector to scan only the active
parts of the stacks during each cycle, not the entire stack. Crud left
beyond the SP will not cause extra garbage retention (which reminds me
that I need to think about any Red Zone that might be active! I need to
scan somewhat beyond the current SP...)

> 
> > P.S. What about CVS access to RTEMS?
> 
> That one is for Mark to answer.  Ask mark.johannes at OARcorp.com. :)
> 
> > --
> > Charles-Antoine Gauthier
> > Institute for Information Technology   Institut de technologie de
> > l'information
> > National Research Council of Canada    Conseil national de recherches du
> > Canada
> 
> --
> 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

-- 
Charles-Antoine Gauthier
Institute for Information Technology   Institut de technologie de
l'information
National Research Council of Canada    Conseil national de recherches du
Canada