Incremental pattern matching in the VIATRA2 model transformation framework

BudapestUniversityofTechnologyandEconomicsDepartmentofMeasurementandInforma<onSystems

BudapestUniversityofTechnologyandEconomics

Incrementalpa,ernmatchingintheVIATRA2modeltransforma9on

framework

IstvánRáth([email protected])

Overview

  Introduc9ontoGTo fromtheVIATRA2perspec9ve

  Incrementalpa,ernmatchingwithRETE

  Ini9alPerformanceanalysiso Incrementalvs.Localsearch

 Finetuningo Paralleliza9ono HybridPa,ernMatching

 OngoingResearch/Futurework Summary

INTRODUCTION

GraphTransforma9onsfromtheVIATRA2perspec9ve…

BME‐MITMiniszimpózium2009

MDA,DSMinprac9ce

CORBA model

J2EE model

Embedded platform model

CORBA application

J2EE application

Embedded application

Domain-specific models

Platform-specific models

Application

PIM

Legacy code

Modeling (re-engineering)

BME‐MITMiniszimpózium2009

MDA,DSMinprac9ce

CORBA model

J2EE model

Embedded platform model

CORBA application

J2EE application

Embedded application

Domain-specific models

Platform-specific models

Application

PIM

Legacy code

Modeling (re-engineering)

Applica9onsofVIATRA2

Domain‐specificviews

6

ICGT'08

Metamodel

Metamodeling

tkn3:tokens

a4:outarc

a1:inarc a2:outarc

a3:inarc

inarc

outarc 11

* *

At most one

Arbitrary

p1:Place p3:Place

t2:Transition

t1:Transition

to1:Token

Transition

Place

Object

Link

Slot Instance model

Class

Association

Multiplicity constraint

Token

1

*

tokens

GraphTransforma9on 7

Phases of GT matching –  Pattern Matching phase –  Updating phase: delete+ create

LHS RHS

Place

Token

Tran. Place a1:inarc a2:outarc

Place

Token

Tran. Plan a1:inarc a2:outarc

ttn1:tokens tkn2:tokens

matching updating

Pattern Matching is the most critical issue from performance viewpoint

Incrementalmodeltransforma9ons  KeyusagescenariosforMT:

o Mappingbetweenlanguageso  Intra‐domainmodelmanipula9on

•  Modelexecu9on•  Validitychecking(constraintevalua9on)

  Theyworkwithevolvingmodels.o Usersareconstantlychanging/modifyingthem.o Usersusuallyworkwithlargemodels.

  Problem:transforma9onsareslowo Toexecute…(largemodels)o  andtore‐executeagainandagain(alwaysstar9ngfromscratch).

  Solu9on:incrementalityo Takethesourcemodel,anditsmappedcounterpart;o Usetheinforma9onabouthowthesourcemodelwaschanged;o Mapandapplythechanges(butONLYthechanges)tothetarget

model.

Towardsincrementality

 Howtoachieveincrementality?o Incrementalupdates:avoidre‐genera9on.

• Don’trecreatewhatisalreadythere.• Usereference(correspondence)models.

o Incrementalexecu+on:avoidre‐computa9on.• Don’trecalculatewhatwasalreadycomputed.

• How?

INCREMENTALGRAPHPATTERNMATCHING

WiththeRETEalgorithm,asimplementedinVIATRA2

Incrementalgraphpa,ernmatching Graphtransforma9onsrequirepa,ernmatching

o Mostexpensivephase

 Goal:retrievethematchingsetquickly How?

o Store(cache)matcheso Updatethemasthemodelchanges

• Updateprecisely  Expectedresults:good,if…

o Thereisenoughmemory(*)o Queriesaredominanto Modelchangesarerela9velysparse(**)o e.g.synchroniza9on,constraintevalua9on,…

Opera9onaloverview

XForminterpreter

VIATRAModelspace

Incrementalpa,ernmatcher

modelmanipula9on

eventno9fica9on

pa,ernmatching

updates

VIATRAModelspace

Coreinterfaces

XMLserializer

Na9veimporter&loaderinterface

XForminterpreter

LSpa,ernmatcher

VIATRA

2Framew

ork Programmodelstore

Incrementalpa,ernmatcher

Modelparser

XFormparser

Architecture

p2

p1

p3

INPUT

Coreidea:useRETEnets

  RETEnetworko  node:(par9al)matchesofa

(sub)pa,erno  edge:updatepropaga9on

  Demonstra9ngtheprincipleo  input:Petrineto  pa,ern:fireabletransi9ono  Modelchange:newtransi9on

(t3)

:Place

t2

:Transi9on:Token

t1

k2k1

k2k1

p1p2 t2t1

p2,k2p1,k1

p2,k2,t3

p1,k1,t1,p3

t3t3

t3t3 t3

p1p2p3 t2t1

t3

t3

p1,k1,t1

p2,k2,t2,p3

p3

t3

p2,k2,t3

Inputnodes

Intermediatenodes

Modelspace

Produc9onnode

RETEnetworkconstruc9on  Key:pa,erndecomposi9on

o Pa,ern=setofconstraints(definedoverpa,ernvariables)o Typesofconstraints:type,topology(source/target),hierarchy(containment),a,ributevalue,generics(instanceOf/supertypeOf),injec+vity,[nega9ve]pa,erncalls,…

  Construc9onalgorithm(roughly)o 1.Decomposethepa,ernintoelementaryconstraints(*)o 2.Processtheelementaryconstraintsandconnectthemwithappropriateintermediatenodes(JOIN,MINUS‐JOIN,UNION,…)

o 3.Createterminatorproduc9onnode

KeyRETEcomponents

  JOINnodeo ~rela9onalalgebra:naturaljoin

 MINUS‐JOINo Nega9veexistence(NACs)

INPUTINPUT

INPUT

JOIN

JOIN

PRODUCTIONsourcePlace

Suppor9ngarichpa,ernlanguage  Pa,erncalls

o Simplyconnecttheproduc9onnodeso Pa,ernrecursionisfullysupported

 OR‐pa,ernso UNIONintermediatenodes

  Checkcondi9onso check(value(X)%5==3)o check(length(name(X))<4)o check(myFunction(name(X))!=‘myException’)o Filterandtermevaluatornodes

  Result:fullVIATRAtransforma9onlanguagesupport;anypa,erncanbematchedincrementally.

Updates Neededwhenthemodelspacechanges

 VIATRAno9fica9onmechanism(EMFisalsopossible)o Transparent:usermodifica9on,modelimports,resultsofatransforma9on,externalmodifica9on,…RETEisalwaysupdated!

  Inputnodesreceiveelementarymodifica9onsandreleaseanupdatetokeno Representsachangeinthepar9almatching(+/‐)

 Nodesprocessupdatesandpropagatethemifneededo PRECISEupdatemechanism

PERFORMANCEANALYSIS

Performance  Intheory…

o Buildingphaseisexpensive(“warm‐up”)•  Howexpensive?

o Oncethenetworkisbuilt,pa,ernmatchingisan“instantaneous”opera9on.

•  Excludingthelinearcostofreadingtheresultset.o But…thereisaperformancepenaltyonmodelmanipula9on.

•  Howmuch?

 Dependencies?o Pa,ernsizeo Matchingsetsizeo Modelsizeo …?

21

ICGT'08

Benchmarking

  Aim:o systema9candreproduciblemeasurementso onperformanceo underdifferentandpreciselydefinedcircumstances

  Overallgoal:o helptransforma9onengineersinselec9ngtools,finetuningop9ons

o Serveasreferenceforfutureresearch  Popularapproachindifferentfields

o AIo rela9onaldatabaseso rule‐basedexpertsystems

22

ICGT'08

Benchmarkingingraphtransforma9on

  Specifica9onexamplesforGTo Goal:assessingexpressivenesso UML‐to‐XMI,object‐rela9onalmapping,UML‐to‐EJB,etc.

  „Generic”PerformancebenchmarksforGTo Varróbenchmarko R.GeißandM.Kroll:OnImprovementsoftheVarróBenchmarkforGraphTransforma<onTools

o (Ag<veToolContest,Grabats’08,…)  OurICGT’08paper:Benchmarksforgraphtransforma<onwithincrementalpa_ernmatchingo simula9ono synchroniza9on

Petrinetsimula9onbenchmark  Exampletransforma9on:Petrinetsimula9on

o Onecomplexpa,ernfortheenablednesscondi9ono Twographtransforma9onrulesforfiring(tokensarere‐created)o As‐long‐as‐possible(ALAP)styleexecu9on(“fireatwill”)o Modelgraphs:

•  A“large”Petrinetactuallyusedinaresearchproject(~60places,~70transi9ons,~300arcs)

•  Scalingup:automa9cgenera9onpreservingliveness(upto100000places,100000transi9ons,500000arcs)

  Analysiso Measureexecu9on9me(averagemul9pleruns)o Take“warm‐up”runsintoconsidera9on

  Profilingo Measureoverhead,networkconstruc9on9meo “Normalize”results

Profilingresults Modelmanipula9onoverhead:~15%(ofoverallCPU9me)o Dependslargelyonthetransforma9on!

 Memoryoverheado Petrinets(withRETEnetworks)upto~100000fitinto1‐1.5GBRAM(VIATRAmodelspacelimita9ons)

o Growslinearlywithmodelsize(asexpected)o Natureofgrowthispa,ern‐dependent

 Networkconstruc9onoverheado Similartomemory;pa,ern‐dependent.o PN:InthesameorderasVIATRA’sLSheuris9csini9aliza9on.

Execu9on9mesforPetrinetsimula9on

10

100

1000

10000

100000

1000000

100 1000 10000 100000

Execu<

on<me(m

s)

Petrinetsize

SparsePetrinetbenchmark

Viatra/RETE(x1k)

Viatra/LS(x1k)

GrGenNET(x1k)

Viatra/RETE(x1M)GrGen.NET(x1M)

Threeordersofmagnitudeand

growing…

Matches/outperformsGrGEN.NETforlargemodelsandhighitera9oncounts.

26

ICGT'08

Object‐Rela9onalMapping:Synchroniza9on

orphanTable

C: Class

T : Table

: tablerRef

NEG

OR

A: Association : tableRef

{DEL}

: Package

: Class

: Attribute : Attribute

: Schema

: Table

: Column : Column

:schemaRef

:columnRef

:tableRef

:columnRef

Sync order 1. Orphan schema delete 2. Orphan Tableclass delete 3. Orphan Tableassoc delete 4. Orphan Columnattr. Delete 5. Renaming 6. new Classes/Assocs/Columns

created

27

ICGT'08

Object‐Rela9onalMapping:Synchroniza9on

 Test Case generation −  Fully connected graph −  N classes −  N(N-1) directed association −  K attributes

  Execution −  Phases

1.  Generation 2.  Build 3.  Modification 4.  Synchronization

−  Measured: Synchronization phase

Paradigm Features ORM Syn. LHS size large fan-out medium

matchings PD transformation

sequence length PD

 Characteristic

 Source modification −  1/3 classes deleted −  1/5 associations deletes −  ½ attributes renamed −  1 new class added and the fully

connected graph is rebuilt

28

ICGT'08

ORMSynchroniza9onbenchmarkresults

• Execution time: • RETE: linear • LS: exponential

Wrt. number of affected elements

29

ICGT'08

Varró:STSBenchmark• Non reusable model elements • Suites better for LS

Ini9albenchmarking:summary

 Predictablenear‐lineargrowtho Aslongasthereisenoughmemory

o Certainproblemclasses:constantexecu9on9me

  Benchmarkexampledescrip9ons,specifica9ons,andmeasurementresultsavailableat:o h_p://wiki.eclipse.org/VIATRA2/Benchmarks

FINETUNINGPERFORMANCE

Improvingperformance  Strategies

o Improvetheconstruc9onalgorithm• Memoryefficiency(nodesharing)•  Heuris9cs‐drivenconstraintenumera9on(basedonpa,ern[andmodelspace]content)

o Parallelism• UpdatetheRETEnetworkinparallelwiththetransforma9on•  Supportparalleltransforma9onexecu9on•  PaperatGT‐VMT’09:Paralleliza9onofGraphTransforma9onBasedonIncrementalPa,ernMatching

o Hybridpa,ernmatching•  „mix”pa,ernmatchingstrategies,useeachatitsbest•  PaperatICMT’09:Efficientmodeltransforma9onsbycombiningpa,ernmatchingstrategies

Concurrentpa,ernmatching

 Asynchronousupdatepropaga9oninRETE Concurrenttothetransforma9on

o Waitforupdatepropaga9ononlywhenquerying

transforma9on RETE

querysourcePlace

tokenremovedno<fica<on

tokenremovedno<fica<on

querytargetPlace

tokenaddedno<fica<on

asynchronous

asynchronous

asynchronous

instantaneous

synchronizing

ConcurrentPMPerformance

 Theore9calexpecta9ons

  Ini9almeasurements

Pa_ernmatcher Updateoverhead Pa_ernquery

LS 0 slow

RETE large instantaneous

concurrentRETE smaller instantaneous,poten9alwait

Pa_ernmatcher N=7 N=8 N=9 N=10

LS 0.8s 3.2s 37s 390s

RETE 0.8s 2.6s 8.3s 26.2s

concurrentRETE 0.8s 2.2s 6.9s 22.8s

20%speedincrease

Mul9‐threadedpa,ernmatching

 Mul9‐threadedRETEpropaga9ono Nodesetpar99onedintocontainerso Dedicatedupdatepropaga9onthreadpercontainer

p2,k2p1,k1

p1,k1,t1,p3

p1,k1,t1

Placep1p2p3

Transi9ont2t1

p3,k2,t3

t3

p3,k2,t2,p2

t3

p3,k2,t3

Tokenk2k1

Pa,ernquery:waitfortermina9on!

OK!OK!

OK!

Whoops…

Detec9ngthefixpointisnontrivialTimestamp‐basedsynchroniza9onprotocol

thread1 thread2 thread3

Highconnec9vityisbadforperformance

Mul9‐threadedPMperformance

 Highconnec9vityisbadforperformanceo Toomuchsynchroniza9onbetweenthreads…

o Par99ongranularity:i.e.pa,ern‐wiseo Transforma9onpartsusingindependentpa,erns?o Intelligentarrangement?

Parallelruleexecu9on

 Ruleexecu9onisdominant(ifPMisfast)o Thereismoretogainthere!

 Problem:parallelrulesmustnotconflicto Coreconflicts:seecri9calpairanalysiso Pa,erncomposi9on,recursion…o Parallelrulesrequirethread‐safePM,model

 Exclusion/locksarerequired

thread1 RETE

tokenremovedno<fica<on

thread2

tokenremovedno<fica<on

lockbythread2

lockbythread1

Evalua9ngparallelperformance

 Performanceevalua9ono Codegenera9on:readonly

o GraBaTs‘08AntWorldbenchmark:4CPUs,wasslower

 Observa9on:lockscanbecomebo,lenecks

 Proposedsolu9onso Par9allocking?Rule‐levellocking?

 Read‐intensivetransforma9onispreferable

PNMLgenerator Single Double

Serial 2.9s 5.8s

Parallel 3.7s 3.9s50%speedincrease

Parallelism:lessonslearned

  IncrementalPMmightbegoodforparalleliza9ono Nosearch,shorterlocking!

  IncrementalPMmightbebadforparalleliza9on!o Updatepropaga9onkeepslockslongero Concurrentmatchersolvesthis

 Futureworko Enhancingmodellockingo Clevermul9‐threadingofRETEo Verylargemodels:distributedMT,distributedPM

Hybridpa,ernmatching

  Idea:combinelocalsearch‐basedandincrementalpa,ernmatching

 Mo9va9ono IncrementalPMisbe,erformostcases,but…

• Hasmemoryoverhead!

• Hasupdateoverheado LSmightbebe,erincertaincases

WhereLSisbe,er…

 Memoryconsump9ono RETEsizesgrowroughlylinearlywiththemodelspace

o Constrainedmemorytrashing

 Cacheconstruc9on9mepenaltyo RETEnetworkstake9metoconstructo „naviga9onpa,erns”canbematchedquickerbyLS

 Expensiveupdateso Certainpa,erns’matchingsetisHUGEo Dependslargelyonthetransforma9on

HybridPMinthesourcecode

AssignaPMimplementa9ononaper‐pa,ern(per‐rule)basisabilitytofinetuneperformanceonaveryfinegrainedlevel.

ModifiedORMSynchroniza9onbenchmark

Hybridscalesbe,erwithincreasingmodels!

AntWorldbenchmark

 PaperforaspecialissueinSTTT’09:Experimentalassessmentofcombiningpa,ernmatchingstrategieswithVIATRA2

  In‐detailinves9ga9ono hybridapproacho Transforma9onlanguage‐levelop9miza9ons

AntWorldResults

Linearcharacteris9cretained,slowerbyonlyaconstantmul9plier

Memoryfootprint

Linearreduc9oninmemoryoverhead

Language‐levelop9miza9ons

Modelmanagementop9miza9ons

Op9miza9onsummary

  Inshort:youmaygetalineardecreaseinmemoryforalinearincreaseinexecu9on9meretainscomplexityclasscharacteris9cs

ONGOINGRESEARCH&FUTUREWORK

Event‐drivenlivetransforma9ons  Problem:MTismostlybatch‐like

o ButmodelsareconstantlyevolvingFrequentre‐transforma9onsareneededfor

• mapping•  synchroniza9on•  constraintchecking• …

 AnincrementalPMcansolvetheperformanceproblem,butaformalismisneededo tospecifywhento(re)acto andhow.

  Ideally,theformalismshouldbeMT‐like.

Event‐drivenlivetransforma9ons(cont’d) Anidea:representeventsasmodelelements. Ourtake:representeventsaschangesinthematchingsetofapa,ern.o ~generaliza9on

  Livetransforma9onso maintainthecontext(variablevalues,globalvariables,…);o runasa“daemon”,reactwhenevernecessary;o asthemodelschange,thesystemcanreactinstantly,sinceeverythingneededisthereintheRETEnetwork:nore‐computa+onisnecessary.

  PaperatICMT2008:Livemodeltransforma9onsdrivenbyincrementalpa,ernmatching.

Futurework

 Paralleliza9ono Alotofresearchgoingon(GrGEN.NET,FUJABA,…)o Wehavesometricksle�tobeexplored,too

 Newapplica9onsofincrementalPMo Livetransforma9onsmodelsynchroniza9on,constraintevalua9on,tracemodelgenera9on

o Stochas9cmodelsimula9oncollabora9onwithReiko’sgroup

 Adapta9onofourtechnologytootherpla�ormso ViatraEMF

Summary

  Incrementalpa,ernmatchinginVIATRA2o Aleapforwardinperformance

o Applicabletoothertoolso In‐depthinves9ga9onsrevealedinteres9ngdetails

 Futureo Performancewillbefurtherimproved

o We’reworkingonnewapplica9ons

 Thankyouforyoura,en9on.h,p://eclipse.org/gmt/VIATRA2

h,p://wiki.eclipse.org/VIATRA2