Path: apple!portal!uunet!spool.mu.edu!agate!parc.xerox.com!boehm From: boehm@parc.xerox.com (Hans Boehm) Newsgroups: comp.archives Subject: [comp.os.research] Xerox Portable Common Runtime Message-ID: Date: 18 Apr 92 09:16:13 GMT References: <33219@darkstar.ucsc.edu> Followup-To: comp.os.research Organization: Xerox PARC Lines: 68 Approved: adam@soda.berkeley.edu NNTP-Posting-Host: soda.berkeley.edu X-Original-Newsgroups: comp.os.research X-Original-Date: 17 Apr 92 20:31:52 GMT Archive-name: auto/comp.os.research/Xerox-Portable-Common-Runtime 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).