[gclist] Using GC in embedded system

[wink]

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
simple:)

Thanks,

Wink

---- 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 
>the
>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 
>in
>a world where GC'd threads and non-GC threads cooperate or
>intercommunicate would you have this issue.
>
>Just my thoughts.
>
>Good luck!
>
>Andy
>
>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 
>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
>>>
>>>
>>
>
>*********************************************************************
>*  Andrew Cheadle                    email:  a.cheadle@doc.ic.ac.uk *
>*  Department of Computing           http://www.doc.ic.ac.uk/~amc4/ *
>*  Imperial College                                                 *
>*  University of London                                             *
>*********************************************************************
>
>