[gclist] Using GC in embedded system

[Wink Saville]

Thanks for the info, I've looked at the source code it appears that
"STOP_WORLD" really only stops all of the threads associated with the
current process. Therefore a different process will never be starved for
cycles. If this is so then and another way to skin the cat is to use a
different "process" for the real-time code and the GC'd code and use some
type of IPC between them. The main advantage of this scheme is that there
would be no changes to the GC code.

Are the above statements true?


Thanks,

Wink

----- Original Message -----
From: "David Chase" <chase@world.std.com>
To: "Wink Saville" <wink@saville.com>; <gclist@lists.iecc.com>
Sent: Tuesday, January 15, 2002 9:40 AM
Subject: Re: [gclist] Using GC in embedded system


> At 08:53 AM 1/15/2002 -0800, Wink Saville wrote:
> >I'm interested in using a GC in an embedded system and was wondering how
> >feasible it is to create a program using C++ that has multiple threads
with
> >some threads having there memory GC'd. The problem is some of the threads
> >will be involved in handling real time information and I don't want them
to
> >be delayed while a garbage collection cycle is occurring.
>
> Could be done.  It would require some hacking on the Boehm-Weiser
collector,
> but nothing tremendously out of the ordinary.  You'd need to create a
> small set of leave-me-alone threads that the collector would ignore.
> Necessarily, these threads must either not play with heap pointers, or
> register them while it did handle them ("register" is pretty easy --
> just be sure that there is a globally accessible array of registered
> pointers).
>
> >Is this possible at all?
>
> Yes.
>
> >Is there a GC that will allow this type of segmentation in the system?
>
> NaturalBridge's BulletTrain (Java, not C++) runtime works along these
> lines.  Threads executing native code are not harrassed by the collector,
> though these threads are delayed if they attempt to interact with the
> VM during a collection.  This is with a compacting collector, but JNI
> ref translation fills the role of "registration".
>
> David
>
>