Persistent Object Systems: Design, Implementation, and Use: 9th International Workshop, POS-9 Lillehammer, Norway, September 6–8, 2000 Revised Papers

328 Pages·2001·4.37 MB·English

by  Graham N. C. Kirby (auth.), Graham N. C. Kirby, Alan Dearle, Dag I. K. Sjøberg (eds.)

Lecture Notes in Computer Science 2135
EditedbyG.Goos,J.Hartmanis,andJ.vanLeeuwen
3
Berlin
Heidelberg
NewYork
Barcelona
HongKong
London
Milan
Paris
Tokyo
Graham N.C. Kirby Alan Dearle
Dag I.K. Sjøberg (Eds.)
Persistent
Object Systems
Design, Implementation, and Use
9th International Workshop, POS-9
Lillehammer, Norway, September 6-8, 2000
Revised Papers
1 3
SeriesEditors
GerhardGoos,KarlsruheUniversity,Germany
JurisHartmanis,CornellUniversity,NY,USA
JanvanLeeuwen,UtrechtUniversity,TheNetherlands
VolumeEditors
GrahamN.C.Kirby
AlanDearle
UniversityofSt.Andrews,SchoolofComputerScience
NorthHaugh,St.Andrews,FifeKY169SS,UK
E-mail:{graham/al}@dcs.st-and.ac.uk
DagI.K.Sjøberg
SimulaResearchLaboratory
P.O.Box1080Blindern,0316Oslo,Norway
E-mail:Dag.Sjoberg@ifi.uio.no
Cataloging-in-PublicationDataappliedfor
DieDeutscheBibliothek-CIP-Einheitsaufnahme
Persistentobjectsystems:design,implementation,anduse;9th
internationalworkshop;revisedpapers/POS-9,Lillehammer,Norway,
September6-8,2000.GrahamN.C.Kirby...(ed.).-Berlin;Heidelberg;
NewYork;Barcelona;HongKong;London;Milan;Paris;Tokyo:
Springer,2001
(Lecturenotesincomputerscience;2135)
ISBN3-540-42735-X
CRSubjectClassification(1998):C.2.4,D.2,D.3,D.4,H.2,H.4,F.3
ISSN0302-9743
ISBN3-540-42735-XSpringer-VerlagBerlinHeidelbergNewYork
Thisworkissubjecttocopyright.Allrightsarereserved,whetherthewholeorpartofthematerialis
concerned,specificallytherightsoftranslation,reprinting,re-useofillustrations,recitation,broadcasting,
reproductiononmicrofilmsorinanyotherway,andstorageindatabanks.Duplicationofthispublication
orpartsthereofispermittedonlyundertheprovisionsoftheGermanCopyrightLawofSeptember9,1965,
initscurrentversion,andpermissionforusemustalwaysbeobtainedfromSpringer-Verlag.Violationsare
liableforprosecutionundertheGermanCopyrightLaw.
Springer-VerlagBerlinHeidelbergNewYork
amemberofBertelsmannSpringerScience+BusinessMediaGmbH
http://www.springer.de
©Springer-VerlagBerlinHeidelberg2001
PrintedinGermany
Typesetting:Camera-readybyauthor,dataconversionbyPTP-Berlin,StefanSossna
Printedonacid-freepaper SPIN:10840119 06/3142 543210
Preface
The Ninth International Workshop on Persistent Object Systems (POS-9) took place
at the SAS Radisson Hotel in Lillehammer, Norway, from 6th to 8th September 2000.
Previous workshops in the series have been held in Scotland (1 and 2), Australia (3),
the USA (4), Italy (5), France (6), and the USA (7 and 8). In keeping with those
workshops, POS-9 was short but intensive, fitting 28 papers and panel sessions, a boat
excursion, and some memorable meals into two and a half days.1 The participants’
concentration was no doubt helped by the Northern European weather that prevailed
for most of the workshop.
Continuing a trend experienced over the previous few workshops, POS-9 had
difficulty attracting a high number of papers. Of course it is hard to tell whether this is
a problem with the field of persistent systems itself, or merely a consequence of the
increasing number of workshops, conferences, and journals competing for
submissions. In his Epilogue to the proceedings, Ron Morrison makes some
interesting suggestions for possible improvements to future POS workshops.
Out of a total of 26 submitted papers, 19 were accepted for presentation at the
workshop. Breaking down by region, 6 1/2 came from the USA2, 1 from Africa, 3 1/2
from Australia, and 8 from Europe. In a new development for POS, an equal number
of papers came from England and from Scotland.
All submissions were reviewed by at least three members of the Program
Committee. Several generated significant disagreement among their reviewers; these
papers were accepted on the basis that substantial changes would be needed if they
were to be included in the final proceedings. All such papers were updated
successfully; our thanks go to the PC members who acted as shepherds to oversee the
revisions. Indeed, as usual, the entire process relied on the dedication and hard work
of the PC, and we thank them sincerely.
In full, the Program Committee was:
Ole Anfindsen Atsushi Ohori
Malcolm Atkinson Tamer Özsu
Jean Bacon Fausto Rabitti
Sonia Berman John Rosenberg
Steve Blackburn Peter Schwarz
Richard Connor Liuba Shrira
Laurent Daynès Santosh Shrivastava
Giorgio Ghelli Paul Wilson
Tony Hosking Alex Wolf
Alfons Kemper Stan Zdonik
Eliot Moss Ben Zorn
Dave Munro

1 Photos from the workshop are on the POS-9 web site at
http://www-ppg.dcs.st-and.ac.uk/Conferences/POS9/.
2 Fractional numbers arise from trans-continental collaborations.
VI Preface
During the workshop, presentations were organized into short sessions of (loosely)
related papers, each concluding with a panel during which the various authors had an
opportunity to expand on deeper or more general issues. These proceedings include
reports by the session chairs summarizing these discussions.
It is customary, in reporting on POS workshops, to note any current trends in areas
of interest. The main broad research area addressed at POS-9 remained that of object
stores, accounting for around half of the papers. The remaining papers covered a rich
mixture of system architecture, middleware, and applications. A previously observed
trend of diminishing interest in language design and type systems continued, with the
almost complete dominance of Java as a language platform.
Finally, we acknowledge the generous support for POS-9 provided by the Research
Council of Norway. We thank Ragnfrid Sjøberg and Helle Frøyseth for their excellent
support with the local arrangements, and Helen Bremner for transcribing various
session tapes.
June 2001 Graham Kirby
Alan Dearle
Dag Sjøberg
Table of Contents
Session1:Overview ................................................. 1
GrahamN.C.Kirby
AFrameworkforPersistence-EnabledOptimization
ofJavaObjectStores................................................. 4
DavidWhitlock,AntonyL.Hosking
ArchitectureofthePEVM:AHigh-PerformanceOrthogonallyPersistent
JavaTMVirtualMachine .............................................. 18
BrianLewis,BerndMathiske,NealGafter
Session2:Overview ................................................. 34
StephenM.Blackburn
ASpatiotemporalModelastheBasisforaPersistentGIS.................... 36
ErikVoges,SoniaBerman
ExperiencewiththePerDiSLarge-ScaleData-SharingMiddleware............ 55
MarcShapiro,PauloFerreira,NicolasRicher
TowardPurePolylingualPersistence .................................... 70
AlanKaplan,JohnV.E.Ridgway,BradleyR.Schmerl,KrishnanSridhar,
JackC.Wileden
Session3:Overview ................................................. 84
RichardJones
TransactionalRemoteGroupCachinginDistributedObjectSystems........... 87
MagnusE.Bjornsson,LiubaShrira
Platypus:DesignandImplementationofaFlexible
HighPerformanceObjectStore ........................................ 100
ZhenHe,StephenM.Blackburn,LukeKirby,JohnZigman
EvaluatingPartitionSelectionPoliciesUsing
thePMOSGarbageCollector .......................................... 125
DavidS.Munro,AlfredL.Brown
TMOS:ATransactionalGarbageCollector ............................... 138
JohnZigman,StephenM.Blackburn,J.EliotB.Moss
Session4:Overview ................................................. 157
AntonyL.Hosking
VIII TableofContents
TheMemoryBehavioroftheWWW,orTheWWWConsidered
asaPersistentStore ................................................. 161
NicolasRicher,MarcShapiro
AComparisonofTwoPersistentStorageTools
forImplementingaSearchEngine ...................................... 177
AndreaGarratt,MikeJackson,PeterBurden,JonWallis
Session5:Overview ................................................. 187
LiubaShrira
AnApproachtoImplementingPersistentComputations ..................... 189
EwaZ.Bem,JohnRosenberg
TransparentOrthogonalCheckpointingthroughUser-LevelPagers ............ 201
EspenSkoglund,ChristianCeelen,JochenLiedtke
AnOverviewofUlisse,aDistributedSingleAddressSpaceSystem............ 215
GianlucaDini,GiuseppeLettieri,LanfrancoLopriore
Session6:Overview ................................................. 228
AlanDearle
Hyper-CodeRevisited:UnifyingProgramSource,Executable,andData ........ 232
E.Zirintsis,GrahamN.C.Kirby,RonMorrison
ImplementingOrthogonallyPersistentJava............................... 247
AlonsoMarquez,StephenM.Blackburn,GavinMercer,JohnZigman
Session7:Overview ................................................. 262
SoniaBerman
EventStorageandFederationUsingODMG .............................. 265
JeanBacon,AlexisHombrecher,ChaoyingMa,KenMoody,WaltYao
AnApplicationModelandEnvironment
forPersonalInformationAppliances .................................... 282
OlivierGruber,RaviKonuru
ScalableandRecoverableImplementationofObjectEvolution
forthePJama1Platform .............................................. 292
M.P.Atkinson,M.Dmitriev,C.Hamilton,T.Printezis
Epilogue .......................................................... 315
RonMorrison
AuthorIndex ...................................................... 321
Session 1: Overview
Graham N.C. Kirby
School of Computer Science, University of St Andrews,
North Haugh, St Andrews, Fife, KY16 9SS, Scotland
[email protected]
The first session of the Workshop contained two papers addressing the implemen-
tation of persistence at the abstract machine level. „A Framework for Persistence-
Enabled Optimization of Java Applications“ by David Whitlock [DW] and Antony
Hosking [AH] describes a number of techniques for optimizing Java programs by
byte code transformation. Rather than treating persistence as a problem, the work
exploits the presence of byte code in a persistent store to allow certain cross-class
optimizations that are not viable in non-persistent Java implementations.
The second paper, „Architecture of the PEVM: A High-Performance Orthogonally
Persistent Java™ Virtual Machine“ by Brian Lewis [BL], Bernd Mathiske [BM] and
Neal Gafter, describes the PEVM, a new implementation of orthogonal persistence
for Java. PEVM runs significantly faster than previous implementations. It can also
handle larger data sets and has a simpler structure.
During questions, Steve Blackburn [SB] asked Whitlock and Hosking how far their
optimizations depended on orthogonal persistence. The response was that it was not
always intrinsically necessary, but that it made certain optimizations economically
viable where they might not be otherwise.
Alan Dearle [AD] asked whether the optimization costs varied linearly with
program length, to which Whitlock replied that the relationship was in fact n2. Then
asked whether this meant that optimization was tractable in practice, he said that it
was, since the programs in question were likely to be of the long-lived server type, in
which the costs of optimization would be amortized over a relatively long time frame.
Ron Morrison [RM] asked Lewis and Mathiske to justify their design assumptions
that direct pointers and explicit read barriers would lead to high performance. He also
questioned the emphasis on scalability, observing that if a user only wanted to run
small applications then it was more important for the system to run fast than for it to
scale.
The authors acknowledged that efficiency at the small scale should not be
sacrificed for scalability, for a general-purpose system. On the design decisions, Tony
Printezis [TP] said that the big advantage of using direct pointers rather than fault
blocks was that allocation was faster. Lewis and Mathiske stated that they had
avoided using fault blocks or handles because of experience with PJama Classic, in
which the cost of managing handles was significant compared with the cost of
managing objects.
Malcolm Atkinson [MPA] followed up on the issue of using operating system traps
versus explicit read barriers. Mathiske said that he had measured the cost of traps in
Solaris, and they cost in the order of 105 cycles, which was clearly too slow.
Liuba Shrira [LS] asked why they had not been able to run the T2b benchmark on
PJama Classic—Lewis answered that they just could not find any combination of
system parameters that made it work. Mathiske added that an advantage of the PEVM
G.N.C. Kirby, A. Dearle, and D.I.K. Sjøberg (Eds.): POS-9, LNCS 2135, pp. 1-3, 2001.
© Springer-Verlag Berlin Heidelberg 2001
2 G.N.C. Kirby
was that it didn’t have so many parameters to tune. Shrira also asked about their
experience with log structured stores, and making Swing and AWT persistent.
Mathiske replied that he had implemented a simple log structured experiment along
the lines of Lumberjack, but that its size was limited by its use of memory mapped
files, and so it was not really comparable with the PEVM store. On making
Swing/AWT persistent, Lewis and Mathiske said that a number of techniques had
been needed to make them restartable after a stabilization. One problem was that C
space allocated for GUI elements needed to be recreated on restart. This was tackled
by a mechanism allowing callbacks to be assigned to particular objects; these could
be invoked either at restart time, or when the object was first faulted during a run.
These hooks were incorporated without changing the Swing/AWT APIs. When asked
how many places in the code had been affected in this way, Mathiske replied that it
was a couple of dozen callbacks—which was hastily amended to about 200 within the
same sentence! Lewis remarked that an unfortunate aspect of JDK 1.2 was that more
things had been implemented in C than in previous versions.
Dearle asked for clarification of one set of performance figures, comparing the
PEVM and the original Research VM running a non-persistent application that
generated purely transient objects. Lewis responded that the figures showed the cost
of persistence support in PEVM: read and write barriers were always emitted whether
they were necessary or not. He also pointed out PEVM’s poor performance on the T6
benchmark, which he said was due to a higher number of garbage collections, since
all objects were made slightly larger by the greater header overhead.
The general panel session started with a question from Morrison, who asked the
panel to consider how systems could be built to allow optimization for various
different applications with widely differing requirements. He gave the example of a
query that touched every object only once, in which case many of the mechanisms
described earlier would be redundant and introduce unnecessary overhead.
Mathiske responded that it was a straight trade-off between specific and general
mechanisms. It would always be possible to build a faster specific mechanism for a
particular application, but if the goal was to provide general purpose support then it
was less important to be the fastest, or even fast, than to not be devastatingly slow!
Hosking replied that the key was to come up with a core set of abstractions to
make the programmer’s life easier, that could be implemented efficiently.
Whitlock agreed more with Ron, saying that we needed some way to characterise
the nature of various applications so that specific persistence support products, such
as orthogonally persistent languages and object databases, could be geared towards
appropriate applications. Mathiske responded to this, saying that their persistent
languages were optimized towards random access—and that for applications
exhibiting a significant amount of linear behaviour, a relational database might well
perform better.
Atkinson then observed that the two papers in the session went well together, in
that the Purdue optimizations could be profitably combined with the Sun technology.
However, this had not happened. He thought this was down to a fundamental trade-
off with how well programmers could perform, given that they were more expensive
than CPUs. Atkinson said that both groups had obviously needed to do a huge amount
of work on the VM source code, and asked how future experiments could be made
easier. Lewis replied that starting with a simpler VM would have made things a lot
easier. Mathiske followed up with a comment that a fully bootstrapped VM, without a
C runtime, would be beneficial.