virtual void DisplaySelf()
};
AninstanceoftheContextclassiscreatedandinitialisedbytheGRTwhenneeded.
Create is called to reserve a memory region for holding objects. Typically,
lan-guagesusethisprimitivetoallo cate spacefortheirobjects. The Create
prim-itivereturnstheaddress of theallo catedmemory.
Register is called to make the sp ecied object (represented by the VMemAdd
pa-rameter)known to the generic run-time. The GName parameter indicates the
global nameoftheclass forthisinstance. The Objectparametercontains the
setofup-callsrequiredforintheregistrationpro cedure,andmustb epreviously
created and initialisedbythecorresp onding languagesp ecicrun time.
Asso ciateGName() asso ciates a global name to the object lo cated at VMemAdd
address. The globalnameisreturned.
Invokecauses invo cation to b e transferred tothe objectsp ecied byGName with
the prameterssp ecied byActivationData.
IsLo cal returns true if the object sp ecied by GName is mapp ed in the current
address space.
LoadObject maps the designated object in virtual memory so that it can b e
scanned withoutb eing invoked. The object stayslo cked inmemory until itis
explicitlyreleasedwith theReleaseObjectprimitive.
ReleaseObject informs the system the designated object is no longer needed in
memory,and thereforecan b e storedbacktodisk.
SetCurrentSignalObject informs the system that thedesignated object should
b ecome the default handler for hardware traps o ccuring within the current
address space.
GroupiscalledtoinformtheGRTthatthelistofobjectsshouldb estoredtogether.
addressspace. It isused forthesamepurp oses astheAfterMapmetho d.
Trap is up-called when a hardware or system exception is raised, and allows the
languagerun-timetohandle exceptions caughtbythe virtualmachine.
Dispatch isup-called bytheGeneric Run-Timewhen an incoming
cross-address-space invo cation for the object is received, and when the object is mapp ed
lo cally.
GetClassreturnsthe globalnameof theclassobjectforthisobject.
GetVMemAdd retrievestheaddressof theobjectinstance data.
GetArrayRefis up-called when the genericrun-time needs toknowthelo cation
of references within an object. The structure returned is an arraycontaining
header information and a list of osets, containing the lo cation of references
within the object. The nal address of the references is obtained by adding
these osetstotheobjectlo cation,returnedbytheGetVMemAddup-call.
ConvertFormat isup-called when an object'srepresentationneed tob e
convert-ed toone suitableforanotherarchitecture. Conversionb etween heterogeneous
architectures is p erformed in two steps: from current format to a standard
one (within thecalling address space), and then fromthe standardto the
de-sired format(within the called address space). Thus, one of the Architecture
argumentsis guaranteed tob ea standardone.
ConvertActivationDataisup-calledtoconverttheparameterscontainedwithin
an ActivationDatastructure. Thesemanticsofthisprimitiveissimilartothe
previous one.
B Class context
An instance of the Context class is created and prop erly initialised by the GRT when
an addressspace iscreated. The op erationsavailableonthisclassdescrib ethedowncalls
availabletolanguagesp ecic runtimes.
class Context {
public:
VMemAdd Create(int size, Error *error);
void Register(VMemAdd vMemAdd, GName gName, Object *object,
Error *error);
GName AssociateGName(VMemAdd vMemAdd, Error *error);
void Invoke(GName gName, ActivationData *actData, Error *error);
Bool IsLocal(GName gName, Error *error);
void LoadObject(GName gName, Error *error);
void ReleaseObject(GName gName, Error *error);
This class describ es the up calls which must b e provided by a Comandos object. Each
languagelevel object must have thefollowing set ofmetho ds availablewhen it wishesto
b e managedbythesystem:
// Structure used to pass parameter frames between language specific runtimes
// and the generic runtime
struct ActivationData {
char *operationName; // String containing the name of the operation
int parametersSize; // Size of the parameters
char *parameterBlock; // raw data containing the parameters
GName targetObject; // Global name of the invoked object, defined
// later.
};
class Object {
public:
~Object(Error *error);
virtual void AfterMap();
virtual void BeforeUnMap();
virtual void Trap(int trapName);
virtual void Dispatch(ActivationData *actData, Error *error);
virtual GName GetClass();
virtual VMemAdd GetVMemAdd();
virtual RefLocation *GetArrayRef();
virtual VMemAdd ConvertFormat(Architecture *from,
Architecture *to, Error *error);
virtual VMemAdd ConvertActivationData(ActivationData *actData,
Architecture *from,
Architecture *to, Error *error);
virtual String ExplainError(Error *error)
virtual void DisplaySelf()
};
Objectdenesthesetofmetho dsthatallComandosobjectsmustsupp orttob e
cor-rectlymanagedbythesystem. Typically,thesemetho dsaregeneratedautomatically
or areinheritedbyeachobjectinthesystem.
AfterMapisup-calledimmediatelyafterthemappingoftheobjectintoanaddress
Inthiscase b oththeobjectitself(if itis b eingmapp ed fromthestorage subsystem)and
the invo cationdatamayneed tob econvertedtothe appropriateformat.
Asfarastheactualobjectisconcerned, inaddition tothemappingandseriesof
asso-ciated up callsdescrib ed insection (4.2.1),we mayneed toup call ConvertFormat(from,
to) which converts to or froma standard architecture indep endent format. In the case
of mappingthe object,itwillb e converted froma standardrepresentationon disktothe
required representationfortheno de.
Dealingwitharchitecturaldierencesattheleveloftheinvo cationdataiscarriedoutin
asimilarmanner. TheGRT,whenitrecognisesthatitissendingtoadierentarchitecture
ensures that the outgoing invo cation frame is converted to an architecture indep endent
one usingtheConvertActivationDate(activationData, from, to)up call. Onreceipt
of an incoming invo cation,the standard representation is converted intoone suitable for
the receivingmachine. Invo cationthen pro ceedsas b eforeusingthe Dispatchfunction.
5 Conclusions
Inthispap erwepresentedthemechanismsprovidedbytheComandosplatformtosupp ort
a varietyof languages intheComandosdistributed environment.
We are currently in the pro cess of implementing the Comandos kernel and GRT on
Unix, CHORUS and Mach 3.0. Language sp ecic runtimes for C++, Eiel and Guide
are also b eing implemented. A prototyp e implementation, known as Amadeus, which
supp ortsdistributedp ersistentC++ab oveUnixiscurrentlyavailabletointerestedparties
for evaluationand exp erimentation.
6 Acknowledgements
Theauthorsacknowledgethefruitfulinteractionswithalloftheparticipatinginstitutions
in the Comandos project and in particular with Bull and IMAG in Grenoble; GMD in
Bonn; andtheUniversityof Glasgow.
The authorsparticularlyacknowledgethe contributionmadebyAndre Kramerwhile
workingatTrinityCollege.
Referen ces
[1] \Functional Sp ecication of Release-2", Esprit Project 2071 - Deliverable D1-T2.3,
March1991.
[2] \ComandosLanguageReferenceManual",EspritProject2071-DeliverableD4-T2.3,
March1991.
[3] I. Goldstein,OSF RI Notes,No3,June 1990.
elsewhere 10
,requiring a remoteinvo cationto b emade.
Here weareonlyconcernedwiththelasttwocases,astherstwillb econnedtothe
language sp ecic runtimeand makesno useof theGRT.
4.2.1 Map the Object Lo cally
When theuse of areference causes an object fault, controlis passed tothe GRT viathe
InvokeprimitivepassingasparameterstheglobalnameoftheobjectandActivationData
- a structure holding the metho d identier and parameters for theinvo cation. It should
b enotedherethattheco dehandlingtheobjectfaultmustmakeamappingfromthelo cal
C++ virtual memory p ointertoa valid Comandosglobal name.
InvokecausestheGRTtolo cate theobject. Wewillassume herethattheobjectwill
b e mapp edintothe callingobject'saddressspace.
The GRT uses an internal service tolo cate the object. It then mapsthe object into
the current address space (c.f. section 2). Once mapp ed, the GRT up calls the object's
GetArrayRef() function. This function returns the address of an array of references
contained within the object. This array, in conjunction with the GetVMemAdd() up call
allowstheGRTtoobtaina listof p ointerswithintheobjecttoother objects.
Foreachreference withintheobjecttheGRThasa choice,either itcangoaheadand
load the referenced object, up dating the p ointer 11
or it can arrange that the use of the
reference causesan objectfault 12
.
Once loaded, an up call is madeto the function AfterMap() which is resp onsible for
ensuring thatanycontextdep ende nt data,suchasle descriptorsasdescrib edab oveare
dealtwith (3.1).
Once this has b een carried out, the GRT can then assume that the object is
cor-rectly mapp ed, and initialised, and can up call the function Dispatch(), passing it the
ActivationData structure obtained in the Invoke downcall which allows the language
level to call the correct metho d, after it has carried out any necessary work connected
with stackmanagement.
4.2.2 Map the Object Remotely
The scenario for dealing with an object that is mapp ed remotely is similar to that of a
lo cal invo cationin termsof dealing with the mapping, converting global references etc.
However, thedierenceis inthepropagationofthe invo cationframe.
When the object is mapp ed remotely,the GRT transfer pro cessing from the current
address space to the remoteaddress space 13
. In this case the ActivationData mustb e
transferred tothetheremoteaddressspace.
10
forexample,b ecauseofheterogenei ty
11
andrecursivel y loadotherreferencedobjects.
12
Again viavirtualmemorytechniquesorusingproxyobjects.
13
ToillustratehowtheComandosGRTsupp ortstheC++language,wedetailthecreation
of a C++ object on the Comandos platform and the subsequent invo cation of another
C++object.
4.1 Object Creation
In traditional languages such as C++, language objects can b e instantiated in several
p ossible scop es. An object can b e declared ina global scop e (outsideof any function or
class), and thus reside inthedata space ofthe application;can b edynamicallyallo cated
in the heap of the application, by means of mechanismssimilar to malloc in Unix; can
resideinthestackifdeclaredwithinthescop eofafunctiondenition;andcanexistwithin
another object(whereveritmayb e).
However, this scenarioof object creationis indep endent of the GRT,which do es not
require language objects tob e lo cated in a sp ecic region. Although the GRT provides
theCreatecallforallo catingnewspace, 8
weareneverconstrainedtouseonlythisspace.
The onlyrequirement is that allpromoted objects residein memory known to theGRT.
Thus notalllanguageobjects need b eknowntotheGRT.
Objectstowhichreferences arepassed outsideoftheaddressspaceinwhichtheywere
created (asdescrib edinsection 2)need tob ecomeknowntotheGRT.Thispromotionis
an op eration carried outon demand. Infact,whenever references are sent outside of the
address space,atestneedstob emadetodeterminewhether ornottheyrefer toglobally
known objects. If they refer to volatileobjects,then these objects mustb e promotedby
callingtheRegisterandAssociateGNameprimitivesasdescrib edpreviously. The testis
carried outbylanguagesp ecic co de,i.e. as partof theup calltotheappropriate object.
WhentheRegisterop erationiscalled,thelanguagesp ecicrun-timemustprovidethe
binding tothecorrect up call functions toallowtheGRTtomanage thenewly promoted
objectwithresp ect top ersistence, distributionand contextdep endant data.
Thisco de,thatencapsulatescontextdep endantdataandtheup callfunctionsthat
sup-p ort p ersistence, 9
mayb e generated automaticalyusing eitherpre-pro cessor, orcompiler
adaptations,ormayb ehand generated bytheprogrammer.
Thereaderisdirectedtoapp endixAforafull descriptionoftheup callfunctionsthat
mustexist foreachGRTmanaged object.
4.2 Object Invocation
Whenaninvo cationisattemptedusingavirtualmemoryp ointer,anumb erofeventsmay
b e triggereddep end ingon thestate ofthecorresp ondingobject:
The objectis knownlo callyandtheinvo cationpro ceeds withoutuse of theGRT.
The object is unknown lo cally,causing an 'objectfault',passing intothe GRTand
asking theGRTtolo catethe objectand mapit lo cally.
8
asdescrib edinsection 2
ComandosGRT.
Another problem is the need to deal with p ointers to context dep end ent data, for
exampleledescriptors. Ifwepass aledescriptoroutofanaddressspace,withoutsome
means of conversion, it may b e imp ossible to use that descriptor in any other address
space.
In summary,the languagedesignerhasthree mainproblemstosolve:
Dealingwith contextdep ende nt data.
Managingp ointerstostored objects.
Managingp ointerstoremoteobjects.
3.1 Context Dependent Data
We adoptan approachtocontextdep endent datathatrequiresprogrammerintervention.
Our motivationis that such data is outside the scop e of the object orientedworld,and,
more imp ortantly, the programmer making no use of distribution or p ersistence should
not b econcernedwith theproblem.
Theapproachistoencapsulatesuchdatawithinatyp ethatiscapableofdealingwith
distribution orp ersistence.
Consider for example a le p ointer; if we create a function that the system can call
whenever a le p ointer is passed into or out of an address space, to op en or close the
correct le,then wecan correctlysupp ort thisp ointer.
3.2 Pointers to Stored Objects
Sinceanobjectmaycontainreferencestoobjectsthatarecurrentlyinthep ersistentstore,
we must ensure that any attempt to access such an object causes an 'object fault'. We
are currently exp erimenting withtwo mechanismsfor thispurp ose: The rstmechanism
involvestheuseofaproxyobjecttorepresentthestoredobjectsuchthatwhen accessed,
the proxy is resp onsible for lo cating the correct object and overlaying itself. The
alter-native mechansimistohave references toabsent objects p ointtoinvalidmemorysothat
attemptstoaccesssuchobjectscause memoryfaults. Thuswe cantrap the'objectfault'
without usinga proxy andcan loadtherequiredobjectinthefault handler.
3.3 Pointers to Remote Objects
The solution to the last major problem, that of trapping invo cations to remote objects
and forwarding the request uses a mo del similar to that describ ed ab ove. However, in
the remote case we are alwaysconstrained touse a proxy so thataccesses tothedata of
the object can b e caught. Using a proxy object in place of the remoteobject, we catch
invo cations,lo catetheremoteobject,marshalltheargumentsandsendtheremoterequest
Remoteand Cross-Address-SpaceInvo cation
The GRT co-op erates with the requesting language in p erforming remote and
cross-address-spaceinvo cations. TheGRTsupp ortsthebuildingof parameterframesfor
trans-missionb etweenheterogeneousmachinesbysupplying-tolanguagedep end entRPCstubs
(whichmayb egeneratedbystandardstubcompilers)- genericroutinestoenco de
param-eter datainnetworkformat. Thelanguagesp ecic runtimecanthenp erformmarshalling
intobuersprovidedby theGRTusingtheappropriate GRTroutine toenco de thedata.
TheGRTinteractswiththecommunicationssubsystemand theprotectionsubsystem
to supply the mapping b etween the target objects global name and the authenticated
remoteinvo cationtransp ort path.
Lo cal Garbage Collection
Thecreationofnewobjectsmayleadtoexhaustionofmemory.Torecycleunusedmemory,
the GRT incorp orates a lo cal (p er address space) garbage collector, taking externally
known data objects (which have b een assigned a global name) as its ro ot, and which
collects unreachablevolatile objects.
AstheGRTimp osesno parameterframeformats,thegarbagecollector mustb e
con-servative when scanning stacks 7
. The lo cal collector mustco op erate with on-line global
garbage collection, if it is present. Lo cal garbage collection uses the up call mechanism
to lo cate object references held by typ ed language level objects. The garbage collection
should b ecompactingonlyifdynamicobjectmovementissupp orted bythelanguageand
itssp ecic runtime.
3 Supporting an Object Oriented Langu age above the
GRT
In thissection we examine whatthe majortechnical problems are when mapping a
lan-guage such asC++ontothe ComandosVirtualMachine.
OurgoalistotransparentlyprovidetheC++programmerwithadistributedp ersistent
programming environment. However, we are concerned to minimise the side-eects of
using ourplatformforprogrammers. Thisgeneratestwo,conicting,constraints: thatwe
maintain, as far as is p ossible the current mo del and syntax of the C++ language, yet,
we do not p enalise C++ programmers who make no use of the enhanced functionality
provided.
Both distribution, and p ersistence imp ose a common requirement on the C++
pro-grammingmo delforwhichcurrent compilersdo not cater. Allreferences toobjectsmay
actually p oint to objects that are not mapp ed in the current address space i.e. objects
whichare either mapp edon a machineelsewhere inthe system,orare currentlyinactive
and soareon secondarystorage.
SincecurrentimplementationsofC++usevirtualmemoryp ointerstorefertoobjects
we are faced with a dilemma: either we adapt current compilers to generate globally
unique, long lived object p ointers, or we add supp ort for the GRTto map the compiler
withtheGRTbytheRegistercallwhichasso ciatesanup calltabletotheobjectallowing
it tob emanagedbytheGRT.
To b ecome globally known, the language sp ecic runtime must call the
AssociateGNamefunction whichreturns a globalnameforthe object.
The object cannot now b e garbage collected using address space lo cal information
alone. Theobjectmayb eunmapp edonaddressspacedeletionorwhennolongerrequired
bythe languagerun-time.
Object GlobalNaming
Objects are assigned global names (only) when they are promoted. Thus a lo cation
indep ende nt formof namingis used to transmitobjectreferences outside of theaddress
space in which the object was created. Global names may b e passed in
remote/cross-address-space invo cationsandstoredinthestoragesubsystemalongwiththeobjectwhich
containsthename.
TheGRTinteractswiththestoragesubsysteminallo catingglobalnamessinceaglobal
nameconsists of a secondarystoragecontaineridentierand a generationnumb er which
is unique within that container. The container identier names the secondary storage
containerinitiallysp ecied fortheobject. Iftheobjectmigratesb etween containers,then
the initialcontainer musttracktheobject'scurrent storage lo cation. Volatileforwarding
informationmayb eusedtoaccelerateasearch,butmayb eoutofdateorincompletedue
to no decrashes.
Object Invo cation
Object invo cation is the basic primitive of the mo del reecting all the features related
with transparent handlingof p ersistence,distribution andsharing.
Invo cations on objects mapp ed lo cally are p erformed at language sp ecic run time
level. However, attemptsto access objects which arenot mapp edin the current address
space -objectfaults - aretrapp edbythesp ecic runtimewhichcallstheGRT.Itinturn,
eitherarranges tomaptheobjectintothecurrent addressspace,orarranges tocarry-out
a cross-address-space orremote invo cation asrequired. The GRT may interact with the
protectionsubsystem,storagesubsystemandgloballo cationserviceindetermininghowto
handle theobjectfault. Thefollowingparagraphsintro ducethebasicmechanismswithin
the GRTto handleobject faults.
Object Mapping
When mapping an object, the GRT must rst allo cate memory for the object. The
GRT translates global names contained in the mapp ed object to language names, by
interacting with the mapp ed object's sp ecic runtime. This translationmay b e delayed
untilthe objectis actuallyused (e.g. b eing invoked)iftheobject waspre-fetched. Ifthe
referenced object do esnot currentlyreside inthelo caladdress space,thenthe GRTmay
b e usedtobuild a lo caldata objectwhich represents thereferenced absent object.
ThetranslationfromglobalnametolanguagenameismaintainedintheGRT's
Con-textObjectTable(COT) withintheaddress spacewhere theobjectis mapp ed.
Groups of objects, i.e. clusters, form the actual unit of transfer b etween the GRT
suppliedbya regularcall(down-call).
This two-wayinterface b etween a language-sp ecic runtime and the GRT allows
ob-jects of heterogeneous languages to b e handled commonly by the GRT. This scheme is
sucientlygenericsoastoallowexibleimplementationsofb oththegenericandlanguage
sp ecic runtimes.
The next sectiongivesan overviewof thebasicfunctionalityof theGRT.
2 The Generic Runtime
The GRTprovidesne grainedpassivedataobjects (whichwillb ereferedto,inthisand
subsequent sections, simplyasobjects)towhicha language,throughitslanguagesp ecic
runtime,maybindclassco de. Language levelobjectmo delscan thusb ebuilt. Anobject
may b e uniquely identied by its so-called global name which is sucient to lo cate the
objecteven whenit ismapp edon aremoteno de orstoredinthestorage subsystem.
The GRT provides generic supp ort for lo cal management of these passive objects,
includingtheircreationand p ossiblegarbagecollection. Objects,whichareviewedbythe
GRT simplyas contiguous blo cks of memory, are used to contain and enclose language
levelobjects(referedtoaslanguageobjects)containingb othdirectdataandreferences to
other language objects.
Supp ortedlanguages(i.e. theirlanguagesp ecicruntimes)canbuildlanguagesp ecic
forms ofobjectreferences (refered toaslanguage names),suchas taggedp ointers,which
mayb e storedinlanguageobjects,and thus inobjects whilethey are mapp edintosome
address space.
In particular, the GRT supp orts direct addressing over the objects mapp ed into an
addressspace. Theidentiersforobjectscommunicatedb etweentheGRTandasupp orted
language taketheformof directaddresses 6
.
Theproto colb etweentheGRTandthelanguage(sp ecicruntime)-theup call
mech-anism - allows theGRTto p erforma numb er of op erationson languageobjects,suchas
lo cation oflanguagenamesstoredinlo calobjectsand conversionof thesenamesto/from
global names as objects are mapp ed and unmapp ed. This proto col requires that each
objectmusthaveaminimumset ofmetho ds,oneforeachbasicop erationwhichtheGRT
mayrequest.
Object Creationand Promotion
Objects are brought into existence by the Create call. Create allo cates space, which is
untyp ed, and willb e usedby thelanguage sp ecic run time asa rep ository for language
objects.
Any object created in this way is known as a volatile. Such objects exist and are
known only within the address space in which they were created. Objects may b ecome
knownoutside oftheir addressspace ofcreation(eitherb ecause areference totheobject
has b eenpassed outof theaddress space,orb ecause theobjectitselfmigratesoutofthe
address space). If this happ ens, the object is said to have b een \promoted" to b eing a
globallyknown object.
mandosnotionof a distributed pro cess;
theVirtual Object Memory(VOM) hnadlesallop erationsrelated tothe
manipu-lationof virtualaddressspaces;
theStorage Subsystem(SS) provideslong-termstoragefor p ersistentobjects;
theTransaction Subsystem(TS)supp ortstheexecutionof atomictransactions;
the Communication Subsystem (CS) is resp onsible for providing a generic RPC
interfaceindep endent oftheunderlying stackofproto cols;
the Protection Subsystem (PS) ensures the sp ecied level of protection during
applicationexecution.
Theimplementationof these comp onentsis splitacrossthree interfaces.
the Virtual Machine Interface | The interface across which a supp orted language
communicateswith theComandosplatform;
the Kernel Interface | Dividing those parts of the platform which are accessible
directly by applications (\user" mo de) and those which are accessible only in a
privileged mo de(i.e. theComandos kernel);
the Environment Interface - Theinterfacefroma Comandos implementation toits
underlying hostingenvironment: Unixormicro-kernelslikeCHORUS 5
.
TheVirtualMachineInterfaceistheuniformviewpresentedbytheComandosplatform
toeachofthevarioussupp ortedlanguages. ItisprovidedbytheprimitivesoftheGeneric
Runtime (GRT) layerthat itselfinterfaces withthe servicesof theunderlying Comandos
kernel.
The GRTimplementsthe lo calobjectspace directlymanipulatedby application
pro-gramsi.e. itismainlyconcernedwithlo calobjectmanagement. TheGRTisimplemented
by co de running in usermo de withineach addressspace. Services such asaddress space
creation and deletion; remote invo cation; sharing of objects b etween address spaces as
necessary and objectlo cation withinthedistributed systemmayb e implementedin
ker-nelmo deorbysp ecicserversaswellasinusermo dewithinanaddressspace,dep ending
on theunderlying environment.
As dierent languages have dierent calling semantics, a language specic runtime
must adapt the GRT primitives to the language sp ecic format. Moreover, as most of
these primitives are based on manipulation of objects, whose format and mo del dier
is each of the dierent languages, each sp ecic runtime must also hide these language
dep end encies fromtheGRTsupp ort.
To provide this exibility and to make a minimum numb er of imp ositions on any
language, we prop ose a general mo del in which the language makes calls to the GRT
but exp ects the GRT to understand little of the semantics of these calls. To deal with
theproblemoflanguagesp ecicinformation,thearchitecturemakesheavyuseofup-calls,
applicationdevelopmentand maintenance.
The overall objective of the Comandos project is to identify and construct an
inte-gratedmulti-languageapplicationsupp ortenvironmentfordevelopingandadministrating
distributed applicationswhichcan manipulatep ersistent{long-lived{data. Itis
intend-ed toprovidesuch anenvironmentintheframeworkofmulti-vendordistributed systems.
This platform willallowb oth the development of new applications,and theco-existence
with old-style(Unix 4
oriented) applications.
The Comandosplatformincludesinfrastructure for:
distributedconcurrent computations;
storage and retrievalofp ersistent data;
multipleprogramminglanguages;
reuseableand extensiblesoftwaremo dules;
secure andprotected data;
on-line management,monitoringand control;
access topre-existingapplications and informationsystems;
interworking withnon-Comandosenvironments.
Theprojectisinnovativeinthatitisintegratingop eratingsystems,programming
lan-guagesand databasestechnologies. Theunifyingview isprovidedbya mo delandsystem
architecture based on the object-oriented approach, coupled with p ersistent distributed
storage.
WithintheComandosproject,theobjectparadigmprovidesthebasisforanintegrated
view of applicationconstruction,andsystem management and control.
Theprojectstartedbydeningaconceptualmo delforstructuringdistributed
applica-tions. Thismo deldenestheComandosvirtualmachine,and providesanobject-oriented
view of thedistributed environment.
Based on thismo del, theproject isprovidinga multi-lingualenvironmentwhich
sup-p ortstheconceptsofthemo delthroughvariouslanguages(initiallyC++[5],Eiel[4]and
the Comandosobject-orientedlanguage,knownasGuide[2]).
Inthispap erwedescrib ethesupp ortprovidedbytheComandosplatformforlanguage
implementers and show how an existing language can b e adapted to use the facilities of
the Comandosplatform.
1 The Comandos Virtual Machine
The ComandosVirtualMachineis internallycomp osed ofsix comp onents:
4
SUPPORTING OBJECT ORIENTED LANGUAGES ON THE
COMANDOS PLATFORM
1
VinnyCahill ,ChrisHorn,GradimirStarovic
Distribut ed SystemsGroup,Dept. ofComputerScience , TrinityCollege,Dublin,Ireland.
Ro dger Lea 2
Chorus Systemes,6av. GustaveEiel ,78182St. Quentin-e n-Yveli nes , France
Pedro Sousa
INESC,RuaAlves Redol,9,1000,Lisb oa,Portugal
Abstract
TheComandos project 3
isdesigni ngand implementingaplatformtosupp ort
dis-tributed p ersi ste nt applications. Inparticular the platform supp orts the object
ori-ented style of programming. An essenti al requirement of the Comandosplatform is
thatitmustsupp ortapplicati onswritteninavarietyofexistingaswellasnew(object
oriented)programminglanguages. Moreover,theplatformmustsupp ortinterworking
b etween dierentlanguages. Each languagemaynaturallyhaveits ownobjectmo del
andexecuti onstructures implementedbyalanguage specicruntimesystem. Rather
thanforcingeachlanguagetoadoptacommonobjectmo delandexecutionstructure s
in order toexploit thedistributi on and p ersis tenc esupp ort provided bythe
Coman-dosplatform,Comandosprovidesagenericruntime systemontopofwhichindivid ual
language's sp eci c runtimes mayb e implemented. Inthispap erwe showhowa
lan-guagesp eci cruntimeforanexistinglanguagesuchasC++canb econstructe dab ove
theComandosgeneric runtime.
The growinguse of distributed systemsreectsb oth technologicaland organisational
evolutions. Advances incomputing and networking have ledto theuse of lo cal-area
dis-tributed systems comp osedof heterogeneous workstations and servers. Human
organisa-tionsareoften,bytheirnature,distributed,butwithstrongrequirementsforinterworking
andoverallintegrationwithintheenterprise. Thisevolutionleadscurrentlytotheconcept
of \collectivecomputing"[3],inwhichtheoverallapplicationisconstructedorassembled
frommanycomp onents,each p erformingitsownsp ecialisedfunction.
Thedevelopmentandintegrationofapplicationsoftwareiscurrentlyalab ourand
cost-intensiveprop osition,particularlyfordistributedapplicationswhichhandlelargevolumes
ofstructureddata. Metho dologiesandto olsareneededtomasterthecomplexityinherent
inheterogeneous distributed environmentsand applicationrequirements.
Comandosisprimarilytargetedatthedevelopmentandsupp ortofintegrated
distribut-edapplicationswithinacell,whichconstitutesthebasicorganisationalandadministrative
comp onent withinan enterprise. A cellis comp osedofa setof co op eratingworkstations,
serversand pro cessor p o olsconnectedthrougha high-sp eedlo calarea network. The goal
is topresentthedistributed systemasa coherent entitytoitsusersdespitethevarietyof
1
Thispap erwaspresentedattheEsprittechnical conference,Brussels,1991.
2
emailro [email protected]
