home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / doc / techrepo / 224 < prev    next >
Encoding:
Internet Message Format  |  1992-12-15  |  17.7 KB
  1. Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!agate!darkstar.UCSC.EDU!golding
  2. From: shapiro@yoko.inria.fr (Marc Shapiro)
  3. Newsgroups: comp.doc.techreports
  4. Subject: Reports from INRIA/SOR
  5. Date: 15 Dec 1992 18:07:44 GMT
  6. Organization: INRIA -- Institut National de Recherche en Informatique et Automatique -- Rocquencourt, France
  7. Lines: 372
  8. Approved: compdoc-techreports@ftp.cse.ucsc.edu
  9. Message-ID: <1gl6tgINNa1a@darkstar.UCSC.EDU>
  10. Reply-To: Marc Shapiro <shapiro@corto.inria.fr>
  11. NNTP-Posting-Host: oak.ucsc.edu
  12. Originator: golding@oak
  13.  
  14.  
  15. A number of new publications (articles and tech reports) are available
  16. by anonymous FTP from the INRIA group SOR.
  17.  
  18. For a terse project description and a long bibliography of the SOR
  19. group, retrieve the file SOR.ps.Z.
  20.  
  21. The rest of this message consists of:
  22.         1. FTP instructions
  23.         2. a list of the new reports
  24.         3. abstracts of the new reports
  25.  
  26.                         Marc Shapiro
  27.  
  28. M. Shapiro, INRIA, B.P. 105 Rocquencourt, 78153 Le Chesnay Cedex, France.
  29. Tel.: +33(1)39-63-53-25; fax: +33(1)39-63-53-30; e-mail: marc.shapiro@inria.fr
  30.  
  31. ======================================================================
  32.  
  33.                       1.  F T P   I N S T R U C T I O N S
  34.                       ===================================
  35.                                    
  36. Publications of the INRIA/SOR group available by anonymous FTP:
  37.         Host:      ftp.inria.fr [128.93.1.26]
  38.         Login:     ftp
  39.         Password:  your own e-mail address
  40.         Directory: INRIA/publication/SOR
  41.  
  42. The papers are compressed 300dpi Postscript.  Remember to use FTP `binary'
  43. or `image' mode when transferring compressed files.  Hardcopy can be
  44. ordered by sending e-mail to Nelly Maloisel <nelly.maloisel@inria.fr>.
  45.  
  46. The file README contains a full list of all the papers available by FTP,
  47. ordered most recent first.  (This is the only file in plain ASCII.)
  48.  
  49. The file SOR.ps.Z contains a project description and bibliography,
  50. periodically updated.
  51.  
  52. ======================================================================
  53.  
  54.             2.   L I S T   O F   T H E   N E W   P A P E R S
  55.             ================================================
  56.  
  57. SSPC:rr1799.ps.Z    "SSP Chains: Robust, Dist. References Supporting
  58.             Acyclic Garbage Collection", M.  Shapiro, P.  Dickman,
  59.             D. Plainfoss\'e.  Rapport de Recherche INRIA 1799 and
  60.             Broadcast Technical Report no. 1.
  61.  
  62. KFS:rr-1809.ps.Z    "KFS: Le syst\`eme de fichiers de Kitlog".  C.
  63.                 Fouqu\'e.  Rapport de Recherche INRIA 1809.
  64.                         (In French) 
  65.  
  66. Kitlog:srds.ps.Z    "Kitlog: a Generic Logging Service". M. Ruffin.  11th
  67.             Symp. on Reliable Dist. Systems (SRDS), Houston TX
  68.             (USA), Oct 1992.
  69.  
  70. FI:usenixWinter93.ps.Z    "Fault Interpretation: Fine-Grain Monitoring of Page
  71.                 Accesses", D. Edelson.  1993 Usenix Winter Conference,
  72.                 San Diego CA (USA), jan 1993
  73.  
  74. GFOSFDSS:iwooos92.ps.Z    "A Generic Fragmented Object Structured Framework for
  75.             Distributed Storage Support", H. Soulard, M.
  76.             Makpangou.  3d Int. Workshop on Object-Orientation in
  77.             Operating Systems, Dourdan, France, Sept. 1992.
  78.  
  79. RFOM:iwooos92.ps.Z    "A Refinement of the Fragmented Object Model", P.
  80.             Dickman, M. Makpangou.  3d Int. Workshop on
  81.             Object-Orientation in Operating Systems, Dourdan,
  82.             France, Sept. 1992.
  83.  
  84. DGCOOS:iwooos92.ps.Z    "A Distributed GC for Object Oriented Systems", D.
  85.             Plainfoss\'e, M. Shapiro.  3d Int. Workshop on
  86.             Object-Orientation in Operating Systems, Dourdan,
  87.             France, Sept. 1992.
  88.  
  89. IRCL:iwooos92.ps.Z    "Implementing References as Chains of Links", J.
  90.             Maisonneuve, M. Shapiro, P. Collet.  3d Int. Workshop
  91.             on Object-Orientation in Operating Systems, Dourdan,
  92.             France, Sept. 1992.
  93.  
  94. PC++GC:iwmm92.ps.Z    "Precompiling C++ for Garbage Collection", D.  Edelson.
  95.             Int. Workshop on Memory Management, Saint-Malo (France)
  96.             sept. 1992.
  97.  
  98. EFTGC:iwmm92.ps.Z    "Experience with a Fault-Tolerant Garbage Collector in
  99.             a Distributed Lisp System", D. Plainfoss\'e, M.
  100.             Shapiro.  Int. Workshop on Memory Management,
  101.             Saint-Malo (France) sept. 1992.
  102.  
  103. SPC++:usenixC++92.ps.Z    "Smart Pointers: They're Smart, but They're Not
  104.             Pointers", D. Edelson.  Usenix C++ Conf., Portland OR
  105.             (USA), aug. 1992.
  106.  
  107. ======================================================================
  108.  
  109.                         3.   A B S T R A C T S
  110.               ======================
  111.  
  112. ----------------------------------------------------------------------
  113. SSPC:rr1799.ps.Z
  114.  
  115.               SSP Chains: Robust, Distributed References
  116.                 Supporting Acyclic Garbage Collection
  117.                                    
  118.            Marc Shapiro, Peter Dickman, David Plainfoss\'e
  119. Rapport de Recherche INRIA 1799 and Broadcast Technical Report no. 1.
  120.  
  121.                                ABSTRACT
  122.  
  123. SSP chains are a novel technique for referencing objects in a distributed
  124. system.  To client software, any object reference appears to be a local
  125. pointer; when the target is remote, an SSP chain adds an indeterminate
  126. number of levels of indirection.  Copying a reference across the
  127. distributed system extends an SSP chain at one end; migrating the target
  128. object extends it at the other end.  Invocation through an SSP chain is
  129. efficient: each stage of an SSP chain contains location information and
  130. long chains are short-cut at invocation time.  These actions require
  131. (almost) no extra messages in addition to those of the client application.
  132. The rules for creating, using, modifying and deleting SSP chains are stated
  133. precisely and maintain well-defined invariants.  The invariants hold even
  134. in the presence of message failures (loss, duplication, late delivery);
  135. after a crash, the existence invariants must be re-established.  SSP chains
  136. support distributed garbage collection (GC); we present a robust
  137. distributed variant of reference counting.  The techniques presented here
  138. are cheap, robust, widely applicable, and scalable.
  139.  
  140. ----------------------------------------------------------------------
  141. KFS:rr-1809.ps.Z
  142.  
  143.                        KFS: Kitlog File System
  144.                               (in French)
  145.  
  146.                Carole Fouqu\'e
  147.  
  148.                    ABSTRACT
  149.  
  150. This report describes the design of KFS (Kitlog File System). KFS is a
  151. log-structured file system implemented on top of the general purpose
  152. logging service Kitlog. This work validates the Kitlog model by showing
  153. that services provided by a generic logging tool adequatly support the
  154. specific needs of the file system. As a result, the design of the KFS file
  155. system is simplified, because a number of usefull mechanisms such as free
  156. space management or data lookup are already supported by the Kitlog logging
  157. service.
  158.  
  159. ----------------------------------------------------------------------
  160. Kitlog:srds.ps.Z    
  161.  
  162.                   Kitlog: a Generic Logging Service
  163.                                    
  164.                             Michel Ruffin
  165. 11th Symp. on Reliable Dist. Systems (SRDS), Houston TX (USA), Oct 1992.
  166.  
  167. A generic logging service should cater to the variable and even
  168. antagonistic needs of clients, without imposing unnecessary overhead on
  169. clients that do not use all of its functions.  Kitlog provides an original
  170. solution to this problem by decomposing logging characteristics into five
  171. mechanisms: buffering policy, distribution of records, replication of
  172. records, sharing of logs, and management of physical media.  Each
  173. characteristic is embodied in a class.  For each class, multiple policy
  174. implementations can be provided.  Instances of these classes are stackable
  175. in any appropriate number or order. A client customizes his log, to a
  176. particular set of failure assumptions, by selecting adequate classes,
  177. instantiating them, and connecting the instances together.
  178.  
  179. ----------------------------------------------------------------------
  180. FI:usenixWinter93.ps.Z
  181.  
  182.      Fault Interpretation: Fine-Grain Monitoring of Page Accesses
  183.                    
  184.               Daniel R. Edelson
  185.  
  186.                    ABSTRACT
  187.  
  188. This paper presents a technique for obtaining fine-grain information about
  189. page accesses from standard virtual memory hardware and Unix operating
  190. system software. This can be used to monitor all user-mode accesses to
  191. specified regions of the address space of a process.  Application code can
  192. intervene before and/or after an access occurs, permitting a wide variety
  193. of semantics to be associated with memory pages.  The technique facilitates
  194. implementing complex replication or consistency protocols on transparent
  195. distributed shared memory and persistent memory. The technique can also
  196. improve the efficiency of certain generational and incremental garbage
  197. collection algorithms.  This paper presents our implementation and suggest
  198. several others.  Efficiency measurements show faults to be about three
  199. orders of magnitude more expensive than normal memory accesses, but two
  200. orders of magnitude less expensive than page faults.  Information about how
  201. to obtain the code via anonymous ftp appears at the end of the paper.
  202.  
  203. ----------------------------------------------------------------------
  204. GFOSFDSS:iwooos92.ps.Z
  205.  
  206.          A Generic Fragmented Object Structured Framework for
  207.                      Distributed Storage Support
  208.  
  209.                   Herv\'e Soulard, Mesaac Makpangou
  210.      3d Int. Workshop on Object-Orientation in Operating Systems
  211.                      Dourdan, France, Sept. 1992.
  212.  
  213.                                ABSTRACT
  214.  
  215. We propose a generic framework for storage support in a distributed
  216. environment.  This comprises a set of storage abstractions and storage
  217. policies: data clusters, cluster containers, and container domains,
  218. supporting sharing, caching, and replication.  These abstractions and these
  219. policies are structured as fragmented objects (FOs), such that each storage
  220. system designer can offer the appropriate tradeoffs to its targeted
  221. applications.  The core set of abstractions is discussed, their interfaces
  222. are presented, and the FO-structuring of the cluster abstraction is
  223. detailed.
  224.  
  225. ----------------------------------------------------------------------
  226. RFOM:iwooos92.ps.Z
  227.  
  228.              A Refinement of the Fragmented Object Model
  229.                                    
  230.                    Peter Dickman, Mesaac Makpangou
  231.      3d Int. Workshop on Object-Orientation in Operating Systems
  232.                      Dourdan, France, Sept. 1992.
  233.                                    
  234.                                ABSTRACT
  235.  
  236. Fragmented Objects offer an interesting alternative to the use of uniform
  237. transparent object references in distributed systems.  This novel paradigm
  238. for distributed programming provides facilities for the encapsulation of
  239. policy issues, as well as implementation details such as communication
  240. mechanisms and consistency requirements. At the same time a clean and
  241. comprehensible model is offered to both FO designers and client
  242. programmers.  A number of omissions in earlier papers on this topic are
  243. rectified here, and certain mechanisms are generalised to increase both the
  244. power and the expressiveness of the model.  In particular, FO interfaces
  245. are extended to include upcalls and a new internal model, based on the
  246. fragment factory, is introduced.
  247.  
  248. ----------------------------------------------------------------------
  249. DGCOOS:iwooos92.ps.Z
  250.  
  251.              A Distributed GC for Object Oriented Systems
  252.                                    
  253.                    David Plainfoss\'e, Marc Shapiro
  254.      3d Int. Workshop on Object-Orientation in Operating Systems
  255.                      Dourdan, France, Sept. 1992.
  256.                                    
  257.                                ABSTRACT
  258.  
  259. We describe a distributed garbage collector protocol targeted for
  260. uncooperative distributed object oriented systems.  The protocol has been
  261. implemented on distributed Lisp system and a few performance measurements
  262. are discussed. Since this implementation, we have refined deeply the
  263. protocol to address non FIFO channels. A new reference model is proposed
  264. along with the protocol to improve invocation efficiency.
  265.  
  266. ----------------------------------------------------------------------
  267. IRCL:iwooos92.ps.Z
  268.  
  269.               Implementing References as Chains of Links
  270.                                    
  271.            Julien Maisonneuve, Marc Shapiro, Pierre Collet
  272.      3d Int. Workshop on Object-Orientation in Operating Systems
  273.                      Dourdan, France, Sept. 1992.
  274.                                    
  275.                                ABSTRACT
  276.  
  277. The goal of this work is to provide uniform transparent access to objects,
  278. be they local, remote, persistent, or mobile. In this way, we facilitate
  279. distributed programming and persistence management.
  280.  
  281. An object (the {\em target}) is accessed through a {\em reference}.  A
  282. reference retains its meaning as it is copied, stored, passed in messages,
  283. and as the target migrates.  A reference is used to invoke a procedure (or
  284. {\em method}) of the target object.  References support standard
  285. single-space targets, as well as fragmented objects.  The cost of using a
  286. reference to a local object is comparable to the cost of accessing the
  287. object through a pointer.  In the implementation, a reference is a {\em
  288. chain\/} of {\em links}.  Each link embodies a small piece of
  289. functionality.  A chain may be composed of an arbitrary number of links.
  290.  
  291. ----------------------------------------------------------------------
  292. PC++GC:iwmm92.ps.Z
  293.  
  294.                Precompiling C++ for Garbage Collection
  295.                                    
  296.                             Daniel Edelson
  297.  Int. Workshop on Memory Management, Saint-Malo (France) sept. 1992.
  298.                                    
  299.                                ABSTRACT
  300.  
  301. Our research is concerned with compiler-independent, efficient and
  302. convenient garbage collection for C++.  Most collectors proposed for C++
  303. have either been implemented in a library or in a compiler.  As an
  304. intermediate step between those two, this paper proposes using
  305. precompilation techniques to augment a C++ source program with code to
  306. allow mostly type-accurate garbage collection.  There are two key
  307. precompiler transformations.  The first is automatic generation of {\em
  308. smart pointer\/} classes.  The precompiler defines the smart pointer
  309. classes and the user utilizes them instead of raw pointers.  These smart
  310. pointers supply functionality that allows the collector to locate the root
  311. set for collection.  The second transformation augments the C++ program
  312. with code that allows the garbage collector to locate internal pointers
  313. within objects.  This paper describes the precompiler and the garbage
  314. collector. The paper includes a brief (1500 word) survey of related
  315. techniques.
  316.  
  317. ----------------------------------------------------------------------
  318. EFTGC:iwmm92.ps.Z
  319.  
  320.           Experience with a Fault-Tolerant Garbage Collector
  321.                      in a Distributed Lisp System
  322.                                    
  323.                    David Plainfoss\'e, Marc Shapiro
  324.  Int. Workshop on Memory Management, Saint-Malo (France) sept. 1992.
  325.                                    
  326.                                ABSTRACT
  327.  
  328. In order to evaluate our fault-tolerant distributed garbage collection
  329. protocol, we have built a prototype implementation within a distributed
  330. Lisp system, {\em Transpive}, replacing Piquer's native indirect reference
  331. count distributed garbage collector.  This paper presents our protocol and
  332. highlights implementation issues on Transpive.  In particular, we describe
  333. the prototype and the alterations required to fit into the Transpive
  334. distributed programming model. The message and CPU performance of our
  335. protocol are measured and its fault-tolerance evaluated. We conclude that
  336. the cost of our protocol is close to Piquers's, although our protocol has
  337. greater functionality.
  338.  
  339. ----------------------------------------------------------------------
  340. SPC++:usenixC++92.ps.Z
  341.  
  342.        Smart Pointers: They're Smart, but They're Not Pointers
  343.                                    
  344.                             Daniel Edelson
  345.            Usenix C++ Conf., Portland OR (USA), aug. 1992.
  346.                                    
  347.                                ABSTRACT
  348.  
  349. There are numerous times when a C++ user could benefit from a pointer
  350. variant that has more functionality than is provided by the basic,
  351. language-defined pointer.  For example, type-accurate garbage collection,
  352. reference counting, or transparent references to distributed or persistent
  353. objects, might be implemented with classes that provide pointer
  354. functionality.  The C++ language directly supports one kind of pointer
  355. substitute, the smart pointer, in the form of overloadable indirection
  356. operators: -> and *.
  357.  
  358. In this paper we evaluate how {\em seamlessly\/} smart pointers can replace
  359. raw pointers.  The ideal is for client code not to care whether it is using
  360. raw pointers or smart pointers.  For example, if a typedef selects whether
  361. raw or smart pointers are used throughout the program, changing the value
  362. of the typedef should not introduce syntax errors.
  363.  
  364. Unfortunately, C++ does not support pointer substitutes well enough to
  365. permit seamless integration.  This paper presents the desired behavior of
  366. smart pointers in terms of the semantics of raw pointers that the smart
  367. pointers try to emulate.  Then, we describe several ways of implementing
  368. smart pointers. For each, we show cases in which the smart-pointers fail to
  369. behave like raw pointers.  From among the choices, we explain which is the
  370. best for emulating the standard pointer conversions.
  371.  
  372. Accessors are similar to smart pointers, but have certain advantages.  This
  373. paper discusses the differences between accessors and smart pointers, and
  374. shows why our conclusions about type conversion behavior also apply to
  375. accessors.  Whether a programmer prefers smart pointers or accessors, this
  376. paper shows the limitations and recommends an implementation.
  377.  
  378. ======================================================================
  379.  
  380. The end.
  381. ===========================================================================
  382. Co-moderator:  Richard Golding, Computer & Information Sciences, UC Santa Cruz
  383.         compdoc-techreports-request@ftp.cse.ucsc.edu
  384.  
  385.  
  386.