🚀 go-pugleaf

$@$3$s$K$A$O!#C^GHBg3X$N?7>k$G$9!#(J

$@#P#C#R$K4X$7$F!":#G/!J#1#9#9#2G/!K$N#47n$K(J comp.os.research 
$@$K=P$?5-;v$rH/7!$7$^$7$?!#(J

$@!@!@!!?7>k!!Lw!!!J$7$s$8$g$&!!$d$9$7!K!!!@!@(J
$@!@!@!!C^GHBg3X!!EE;R!&>pJs!!!!!!!!!!!!!!!@!@(J

----------------------------------------------------------------------
From: boehm@parc.xerox.com (Hans Boehm)
Newsgroups: comp.os.research
Subject: Xerox Portable Common Runtime
Message-ID: <33219@darkstar.ucsc.edu>
Date: 17 Apr 92 20:31:52 GMT
Sender: usenet@darkstar.ucsc.edu
Organization: Xerox PARC
Lines: 66
Approved: comp-os-research@ftp.cse.ucsc.edu


A new version of the Xerox Portable Common Runtime(PCR) is available
from

parcftp.xerox.com:~ftp/pub/pcr/pcr4_4.tar.Z

This version is intended primarily for SPARC machines running SunOS.
(A port to something else may require a nontrivial amount of work, in
spite of the name.)

PCR provides:

1) Multiple threads in the same UNIX process with fast thread creation,
locking, etc.  Threads may be scheduled by one or more UNIX processes
sharing memory.  This means that if you have a Sun multiprocessor, they
may be scheduled across multiple processors.  PCR implements its own
blocking I/O primitives that try to block only the thread, and not the
entire UNIX process.

2) Dynamic loading.  It's possible to dynamically link UNIX .o files
into the PCR address space.  It's possible to test modules under PCR by
dynamically loading the latest version of the module into PCR's address
space (by typing the appropriate command at PCR's command interpreter)
and then to call functions from PCR's command interpreter.  This avoids
the potentialy expensive step of relinking an entire program with each
minor change, and thus gives a more Lisp-like flavor to program
development.  This is possible even with C programs.  (Since C usually
provides no protection against random memory smashes, there are also
disadvantages to this approach.)

3) Concurrent conservative garbage collection.

For more detail on PCR in general, see Weiser, Demers, and Hauser,
``The Portable Common Runtime Approach to Interoperability'',
Proceedings of the 13th ACM Symposium on Operating Systems Principles
(December 1989).  The garbage collection algorithm is described in
Boehm, Demers, Shenker, ``Mostly Parallel Garbage Collection'', SIGPLAN
'91 PLDI Proceedings.

PCR has been used to run Cedar, Modula-3, C, Scheme, and Russell code.
It is routinely used to run large amounts of Cedar code at PARC.  Most
existing C programs require conversion to run under PCR, since they
must be thread-safe, and must use PCR I/O calls.  It is usually not
hard to write C code that will run both under both PCR and directly
under UNIX.

Notable changes from the last previously available version (3_4)
include:

1) This one has actually been run on a multiprocessor.  Some obvious
performance bugs were removed as a result.  Lock contention between
UNIX processes is resolved by adaptively busy waiting or executing an
appropriate system call.

2) The collector has been improved.  Pause times should be consistent
with the SIGPLAN paper (though this is a more recent version, and
things may not be exactly the same).  More concurrency is possible
between allocating threads.  Accidental storage retention due to the
conservativism of the collector is less likely.

3) It includes a number of disgusting hacks to either discourage the
UNIX scheduler from favoring one of the PCR UNIX processes over another
for extended periods, or to live with it doing so.

Send questions to boehm@parc.xerox.com.  Don't expect an answer before
the end of next week (4/23/92).