Dear Gentle Persons and Eric,
Has there been any effort to create a LISP version with Real Time
friendly Garbage Collection. Sun's Embedded Java suffers greatly from
the uncontrollable and unpredictable nature of garbage collection. Its
possible they have finally fixed this problem, but considering the number
of design wins that HP's Java version has gotten of late I doubt it. Has
anyone addressed this issue for LISP/scheme. My year old or so information
indicated that in Java garbage collection was the limiting factor in
real time systems minimum response times even when great care was taken to
keep it to a minimum. The alternative is to have all the time critical
software in C or assembly, and only have the highest level in Java. This
obviously eliminates Java for all but the largest of real time systems, or
ones with very slow response time needs. Has anyone addressed this
issue in a LISP system?
Muddy
>>>>> "Robert" == Robert Posey <·····@raytheon.com> writes:
Robert> ... Has anyone addressed this issue for LISP/scheme ...
You should take a look on Rscheme.
I have not worked much with it myself but read some of the
docs. Rscheme supports compilation and tries to ensure certain
properties for instance wrt. GC. It does it by organizing the
generated (sort of C, I think) code into what it call "monotones",
where each monotone is (to some appropriate extent) guaranteed not to
run for too long and not to create too much garbage. GC and thread
switching are then done inbetween monotones.
All of this in my somewhat superficial understanding.
Check out http://www.rscheme.org for the real deal.
---------------------------+--------------------------------------------------
Christian Lynbech | Ericsson Telebit A/S
Fax: +45 8628 8186 | Fabrikvej 11, DK-8260 Viby J
Phone: +45 8738 2228 | email: ···@tbit.dk --- URL: http://www.tbit.dk
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Robert Posey <·····@raytheon.com> writes:
> Has there been any effort to create a LISP version with Real Time
> friendly Garbage Collection?
The LMI Lambda had `real-time' GC, but not much effort was made
to make it `hard' real-time.
Other lisps have been made with more effort put into `real-time'
response.
On Mon, 13 Mar 2000 14:06:03 -0600, Robert Posey <·····@raytheon.com>
wrote:
> Has there been any effort to create a LISP version with Real Time
> friendly Garbage Collection. Sun's Embedded Java suffers greatly from
[...]
> keep it to a minimum. The alternative is to have all the time critical
> software in C or assembly, and only have the highest level in Java. This
If I remember correctly, Gensym used another approach. The company had a
Lisp system for real time applications which didn't use garbage collection
but explicit storage management, i.e. allocation and deallocation was
managed by the programmer. Check the following paper, which describes the
system:
"Real-Time Programming in Common Lisp"
Hallard and Hawkinson
Communications of the ACM, Vol. 34, N.9, September 1991
That CACM issue, by the way, is a special issue devoted to Lisp and
contains other interesting papers.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
In my own humble opinion, hard real time coding can
only be done for extremely limited systems. Simple things
like processes, message queues and disk IO introduce complexities
that cannot be planned for in "hard" systems. These
programming constructs can produce just as much uncertainty
as garbage collection. Really hard time applications use
DSPs or specialized hardware.
What kind of system are you thinking about? Embedded?
Wade
Wade Humeniuk wrote:
>
> In my own humble opinion, hard real time coding can
> only be done for extremely limited systems. Simple things
> like processes, message queues and disk IO introduce complexities
> that cannot be planned for in "hard" systems. These
> programming constructs can produce just as much uncertainty
> as garbage collection. Really hard time applications use
> DSPs or specialized hardware.
>
> What kind of system are you thinking about? Embedded?
>
> Wade
The target system for which Harlequin implemented its real time GC was a
(large) telephone exchange.
- n
From: Christopher C Stacy
Subject: Re: LISP Garbage Collection Timing/Contrl.
Date:
Message-ID: <x8lem9eds77.fsf@world.std.com>
Symbolics and Harlequin both implemented Common Lisp systems for
embedded real-time applications, with guaranteed garbage collection
performance characteristics. (There are probably others.)