[gclist] Using GC in embedded system

wink wink@saville.com
Wed, 16 Jan 2002 10:28:38 -0800

You're right and I'd need to profile the system and put enough
buffering in the RT code to handle the GC delays. Life is never



---- Original Message ----
From: amc4@doc.ic.ac.uk
To: wink@saville.com, 
Subject: Re: [gclist] Using GC in embedded system
Date: Wed, 16 Jan 2002 16:52:23 +0000 (GMT)

>Hi Wink,
>Yes this is one way of doing it. However what you'd want to avoid is 
>RT code waiting for an IPC response while the GC'able code is in
>the process of GCing, but perhaps this is not an issue? Anyway, even 
>a world where GC'd threads and non-GC threads cooperate or
>intercommunicate would you have this issue.
>Just my thoughts.
>Good luck!
>On Wed, 16 Jan 2002, Wink Saville wrote:
>>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 
>>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 
>>would be no changes to the GC code.
>>Are the above statements true?
>>----- 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 
>>> >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
>>> >be delayed while a garbage collection cycle is occurring.
>>> Could be done.  It would require some hacking on the Boehm-Weiser
>>> but nothing tremendously out of the ordinary.  You'd need to 
>create a
>>> small set of leave-me-alone threads that the collector would 
>>> 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 
>>> pointers).
>>> >Is this possible at all?
>>> Yes.
>>> >Is there a GC that will allow this type of segmentation in the 
>>> NaturalBridge's BulletTrain (Java, not C++) runtime works along 
>>> lines.  Threads executing native code are not harrassed by the 
>>> though these threads are delayed if they attempt to interact with 
>>> VM during a collection.  This is with a compacting collector, but 
>>> ref translation fills the role of "registration".
>>> David
>*  Andrew Cheadle                    email:  a.cheadle@doc.ic.ac.uk *
>*  Department of Computing           http://www.doc.ic.ac.uk/~amc4/ *
>*  Imperial College                                                 *
>*  University of London                                             *