[mercury-users] Native garbage collector for Mercury

[Ralph Becket]

Randall Helzerman wrote on 10 Sep:
> > 
> > There is also the point that Unix and Windogs are *not* real-time
> > systems of any kind.  What is the target platform?
> > 
> 
> Here is the "grand plan".  Why is C++ so popular today?  Backward
> compatibility with C.  
> 
> But why is C so popular?  There are dozens of other languages, then and now,
> which would take the crown.
> 
> I would maintain that C is popular for one reason only: UNIX was written
> in it.  Once you own the operating system, you own the world--just as
> Bill Gates found out.

This is a moot point.

> Logic programming in general, and Mercury in particular, are not going to
> become mainstream languages until it is shown that they can be used to
> create an operating system.
> 
> Today, the importance of multimedia means that any new operating system
> must be hard real time.

Whoa!  Multimedia applications are not hard real-time.  Flying an
aircraft and running a nuclear power station and driving a lathe or
photocopier - those are hard real time problems which require a system
to give guaranteed resource and latency guarantees, without which the
specification of the application cannot be bet.  Multimedia apps are
soft real time whereby bounded statistical guarantees are sufficient.
You can have general purpose soft real time operating systems, but I
doubt very much that you can have resource efficient hard real time
OSs.

> I see a definate eco-logic-al niche for a hard real time operating system
> written in Mercury, both for embeded systems (a lot of good work in
> robotics is being pursued in the logic programming tradition, e.g.
> Shanahan, Pool, Macworth, Goebel) and for desktops and servers.

Robotics (et al.) is a different kettle of fish.  The key problems with
higher-level (declarative) languages in this field are

(i) GC can really throw a spanner into time constraints;

(ii) declarative languages tend to stress the memory system a bit
more, leading to problems with hard space constraints;

(iii) there is no obvious mapping from the declarative language to the
underlying hardware, which is a major feature of hard real time
systems.  This is where C scores: it pretty much is just high-level
assembler.  And you can wang bits around very easily without having to
worry about the language runtime system (C hasn't got one).

> I'm sure you can think of many advantages for such an operating system, but
> let me just point out one: distributed computing/RPC.  Suppose you wish to
> provide some service to the internet--say renting out your spare CPU cycles,
> so you accept remote proceedure calls.  But you don't want to let a
> malicious program run, nor one which will loop infinitely.  By using
> abstract evaluation and Mercury's termination analysis, you could screen out
> undesirable potential incomming compute requests.  Moreover, once the
> operating system is written in a pure logical programming language, we
> could begin to think about things like _formally_proving_ that the OS
> is secure.

Well, there is the halting problem.  That aside, what you've just
suggested is not a real time problem, but a security/accounting one.

There is also the problem that many formal spec. jobs end up (after a
great deal of work) showing that the original spec. was flawed.  I
would have thought that a real OS would be way beyond the current
state of the art, either in terms of defining a spec. or turning such
a spec. into an efficient program.

There are many problems with even soft real time systems.  For
example, most current OSs are either monolithic (lots of work and
state inside the Kernel) or server driven (microkernel plus large
trusted service provider processes).  Both of which are a nightmare
for even multimedia apps.  An excellent approach to the problem can be
found in the Cambridge University Computer Lab's OS called Nemesis
(see http://www.cl.cam.ac.uk/Research/SRG/netos.html).  There is good
scope with this architecture for applying declarative stuff to the
higher-level parts of the OS such as the QoS manager (creates
schedules to give statistically bounded resource gurarantees etc.)

Cheers,

Ralph

-- 
Ralph Becket  |  rwab1 at cam.sri.com  |  http://www.cam.sri.com/people/becket.html