FlexSync: An aspect-oriented approach to Java synchronization∗

Charles ZhangDepartment of Computer Science and Engineering

The Hong Kong University of Science and Technologycharlesz@cse.ust.hk

Abstract

Designers of concurrent programs are faced with manychoices of synchronization mechanisms, among which clearfunctional trade-offs exist. Making synchronization cus-tomizable is highly desirable as different deployment sce-narios of the same program often place different prece-dences on synchronization choices. Unfortunately, suchcustomizations cannot be accomplished in the conventionalnon-modular implementation of synchronization. To en-able customizability, we present FlexSync, an aspect ori-ented synchronization library, to enable the modular rea-soning of synchronization and to resolve the coupling be-tween synchronization intentions and mechanisms in Javasystems. With FlexSync, programming synchronization islargely declarative. Complex Java systems can simultane-ously work with multiple synchronization mechanisms with-out any code changes. The FlexSync load-time weaverperforms deployment time optimizations and ensures thesesynchronization mechanisms interact with each other andwith the core system consistently. We evaluated FlexSyncon commercially used complex Java systems and observedsignificant speedups as a result of the deployment-specificcustomization.

1 Introduction

In Java programs, synchronization is commonly referredto as the coordination of multiple threads in accessingshared program states. As concurrency becomes a com-mon programming practice in the multi-core era, the de-signers of concurrent programs are faced with many choicesof synchronization mechanisms such as the use of locks,atomic blocks [7, 8], and, more recently, software transac-tional memory [10, 21]. For their distinctive operational dif-ferences, clear functional trade-offs exist among these syn-chronization mechanisms. This is problematic for building

∗Draft. In ICSE 2009, Vancouver, Canada

general-purpose and reusable Java systems as, in conven-tional approaches, synchronization mechanisms are “hard-wired” to the application logic through the use of libraryAPIs or specialized language constructs. At the same time,choosing the most appropriate mechanism is increasingly adecision made through reasoning about how reusable sys-tems are being integrated in diversified composition con-texts. Let us further elucidate this issue through a simpleexample.

Our example looks at a general-purpose data structure,Buffer, shared by multiple threads in a concurrent pro-gram. Each thread makes accessor calls to store and to re-trieve data from the buffer. We have a consistency rule suchthat these accessor calls (get or set) can only proceed ifthe state of the Buffer is valid (full or empty). In-consistency can happen if, for example, thread A emptiesthe buffer after thread B verifies that the buffer has data andbefore it retrieves the data. There are three popular syn-chronization options: the use of the Java synchronizedkeyword (lock), the block-level atomicity support (BA)using two-phase-locking (2PL) as in [1], and the use ofsoftware transactional memory library(stm) exemplified bydstm2 [10] (Please refer to Section 2 for more introductionon 2PL-based BA and dstm2). In Figure 11, we plot thetime each version takes to complete a fixed number of workunits as the number of concurrent threads increases. Eachwork unit consists of a fixed number of set/get combina-tions. For the lock version, we count successful operationsand perform a retry if any inconsistency is detected. TheBA and STM versions produce no inconsistencies. One caneasily observe that the lock-based approach has the fastestresponse time, whereas the BA implementation is slightlyslower. The performance of the dstm2 version experiencessignificant fluctuations. It can be as fast as the BA approachor 5-6 times slower.

The measurements show that the choice of synchroniza-tion mechanism for Buffer is really dependent on what

1All measurements are collected on a dual-core Linux workstation with4GB of physical memory. The number of total threads ranges from 10 to1000. Each point is taken as the shortest time of five runs.

1

Figure 1. A comparison of response timeamong locks, BA and STM

matters the most to the domain of its application. For in-stance, the use of locks is preferred if high performance is tobe pursued and inconsistencies can be tolerated. The STMapproaches are appealing to the ones requiring transactionalsemantics on the shared states and not sensitive to the fluc-tuations of the processing time. If atomicity is the only re-quired property, applications would prefer the lock-basedatomicity support, which acquires more locks to achieve theconsistency of states and, as the result, sacrifices a certaindegree of concurrency. Therefore, the buffer code, if it wereto be used as a general-purpose building lock of other con-current application, cannot be hardwired with any particu-lar synchronization mechanism afore-listed. The practiceof client-side locking, such as the synchronizedMapmethod of the Collection class, is effective in treatingthis problem for types representing data structures. How-ever, we only use buffer as a problem illustration. Our workconsiders complex reusable Java programs, many are con-current themselves.

Our buffer example poses a paradoxical design chal-lenge: synchronization must be designed and implementedbefore the program can be used; however, the best synchro-nization mechanism is not known until we know about howthe program is used, i.e. its composition context. This de-sign paradox is conventionally resolved if, first, the programfeature is modular, and, second, its interactions with the restof the program can be abstracted for the use of late bindingtechniques. None of the premises holds in the conventionaltreatments of synchronization, the same reason why it isconsidered a classic crosscutting concern [12]. The major-ity of the proposed solutions, including both library-basedand language-based approaches [10, 22, 8, 16], requiresystem-wide code-level commitment to particular synchro-nization mechanisms. The induced inflexibility is detri-mental to reusable Java systems. Our case studies of realcommercial middleware systems show that the performance

overhead caused by this structural rigidity can be as muchas 40%. This problem will exacerbate drastically becausethe degree of reuse and integration will increase dramati-cally [17].

To tackle these challenges, we present FlexSync, in-cluding both an aspect-oriented library and a load-timeweaver, to enable the modular reasoning of synchroniza-tion and the code-level separation of its mechanisms fromreusable Java programs. This separation is possible basedon the observation that, conventionally, the marking of syn-chronization intentions, declaring regions of the programlogic that require special synchronization attention, is animplicit outcome of the direct use of specific synchroniza-tion mechanisms, i.e., library APIs or language keywords.If these intentions have explicit and well-defined code struc-tures, they can be reasoned and manipulated by meta-programming such as AOP [12] as to externalize reusablefeature interactions between synchronization and the coresystem. The design of FlexSync library APIs emphasizeson the ease of “picking out” the intentions where the in-teraction logic, encapsulated in the library, can be auto-matically applied. The FlexSync aspect weaver, an exten-sion to the AspectJ aspect weaver, use static analysis, suchas control-flow analysis and escape analysis, to automati-cally reason about the global composition and interactionof synchronization mechanisms. With FlexSync, the syn-chronization code is modular and lives separately from theoperational code. We show that, through FlexSync, sophis-ticated Java systems can simultaneously work with multiplesynchronization mechanisms of very different genres. Theflexibility and the deployment time optimizations, madepossible by using FlexSync, can significantly improve theperformance for large complex systems.

We make the following contributions in this paper:1. We first present the concept of the separation of in-

tention and mechanism in the context of synchronizationdesign. We empirically show that such separation can beachieved for large-scale and complex Java systems.

2. We present the FlexSync aspect synchronization li-brary, which encapsulates patterns of interactions betweenJava code and the synchronization mechanisms and exposethese patterns through the process of “tagging”. We explainhow the tagging process can attach different synchroniza-tion mechanisms onto the same code structure.

3. We present the FlexSync load-time synchronizationweaver which supports the global reasoning of synchroniza-tion mechanisms in the scenarios of unanticipated compo-sition of reusable systems.

4. We present a thorough evaluation of FlexSync-based synchronization implementations, covering the pro-gramming effort and its functional characteristics. We con-tribute2 the source of the FlexSync library and the systems

2The FlexSync Project. URL:http://www.cse.ust.hk/

2

we experiment with for the interested readers to inspect andto perform further evaluations.

The rest of the paper is organized as follows: Section 2introduces atomicity and the dstm2 implementation of soft-ware transactional memory; Section 3 presents the designmethodology embodied in FlexSync. Section 4 evaluatesFlexSync through standard benchmarks and case studies.

2 Background

Block-level atomicityIn the presence of multiple threads, the block-level atomic-ity means a group of program executions, scoped lexicallywithin a block, is to be carried out serially without theinterference from the inter-leavings of threads. In Javasystems where objects are dynamically allocated, we usea two-phase-lock mechanism to acquire the associatedlocks of all dynamic objects in the control flow of theatomic block. These locks are released after the atomicblock exists. Our implementation is based on the cflowconstructs of AspectJ. Please refer to our source releasefor the details of the implementation.

Software transactional memoryAlso referred to as the optimistic synchronization, softwaretransactional memory (STM) provides runtime infrastruc-tures to keep track of the reads and writes to the shared pro-gram states. It thrives on the optimistic assumptions thatreal data races occur infrequently for many concurrent pro-grams. In STM, a collision can happen when thread B per-forms writes on the shared data after they are read by threadA. Then, the shared states are to be rolled back and the op-eration is re-executed. This can cause the large performancefluctuations because the chance of collision is subjective tothe number of threads and the thread scheduling that can benon-deterministic. The particular STM library used in thisresearch, dstm2, makes copies of the shared states to sup-port rollbacks. This technique is reported to have the fastestruntime performance [10]. STM offers programmers a sim-pler concurrency control mechanism compared to the directuse of locks. In our application of dstm2, we replaced theautomatic state copy capability in the original implemen-tation with a callback method requiring the manual imple-mentations. This is because many reads or writes in the sys-tems that we have experimented with are not performed by“setters” and “getters” as required by the original scheme.

∼charlesz/flexsync

3 FlexSync: the modular and the global rea-soning of synchronization

Following the definitions in [13], the general design goalof Flexsync is to first enable the modular reasoning of syn-chronization through using the FlexSync-API to explicitlyexpress how synchronization mechanisms interact with theoperational logic. At the same time, we address the globalreasoning of the unanticipated program compositions usingthe Flexsync loadtime weave. The rest of the section firstpresent how we achieve these design goals in detail.

3.1 The separation of intention and mech-anism

Synchronization is typically coded as lexical scopes overa group of programming statements, demarcated by eitherlanguage keywords, such as synchronized or atomic,or by library calls, such as the lock/unlock pairs ofsome Lock object. These lexical scopes represent the syn-chronization intentions of the developers, identifying coderegions requiring special synchronization treatments. Werefer to language keywords or API calls used in the de-marcations as the mechanisms, concerning the specific de-cisions of what kind of treatments to apply. These twoconcepts are usually undistinguished in conventional ap-proaches. We advocate their explicit separations as a funda-mental step towards the modular reasoning of synchroniza-tion.

In our current design, the separation is achieved by as-suming that synchronization regions are method-like: thedata flow in these regions can be re-expressed following theinput/output model of a function. This is certainly true formethods prefixed with the synchronized keyword. Forthe synchronization blocks inside method bodies, we per-formed a study of whether these blocks can be automati-cally transformed into methods using the Extract methodfacility of the Eclipse JDT refactoring library. We use anAST walker to retrieve a synchronization block and askthe JDT API to return the refactoring status. We studiedfour open source programs covering four types of serversin which concurrency is extensively used: RPC middleware(ORBacus3), JMS broker (OpenJMS4), web server (Jig-saw5), and database server (Derby6). In our study of theseservers, we encountered three common causes of automaticrefactoring failures: early return (ER), where a returnstatement is nested inside the block, multiple variable as-signment (MV), where multiple local variables are written,and branch selection (BR), where the block resides in a

3ORBacus: URL:http://www.iona.com/orbacus4OpenJMS. URL:http://openjms.sourceforge.net5Jigsaw. URL:http://www.w3.org/Jigsaw6Derby URL:http://db.apache.org/derby/

3

branching block of either if or switch. Among thesefailures, the ER case can be generically treated with by set-ting a condition variable to true inside the refactored methodand checking this condition after the method returns. It re-quires trivial source rewriting and, thus, can be automati-cally treated.

In Table 1, we report the sizes of each program, the us-age of synchronization, as well as the results of invokingthe Eclipse refactoring APIs. Our observation is that ERaccounts for the majority of the refactoring failures, andover 97% of synchronization blocks in all of the four pro-grams can be automatically re-expressed using functions.The non-automatic blocks require manual inspections andcode restructuring. They are small in number and, fromour experience, only require more sophisticated refactoringsteps. Our study validates our design assumption that syn-chronization intentions can be characterized by the methodboundaries.

Program Derby Jigsaw OpenJMS ORBacusSize 915320 160740 112968 189852

Synchronization usagesMethod 294 637 204 466Block 604 149 400 262Total 898 786 604 728

Method Extraction FailuresER 90 11 30 29MV 18 2 9 3BR 8 0 6 2Degree 87.1% 99.7% 92.5% 95.3%Degree 97.1% 98.3% 97.5% 99.3%with ER

Table 1. Summary of Server SynchronizationUsage

3.2 The FlexSync synchronization library

Synchronization perspectives

The design of the FlexSync APIs is based on our obser-vation that different synchronization mechanisms can betreated as different interpretations of the same set of callgraph elements. Suppose that Figure 2(A) represents thecall graph of a fictitious Java program. For the lock-basedapproaches, including the atomicity support, we need toidentify class types encapsulating shared program states aswell as the method interfaces that could lead to data races.This interpretation is illustrated in Figure 2(B). For STM,the interpretation is totally different as, by its optimistic na-ture, it is not concerned with the state sharing and data races.Instead, we need to first identify the class types encapsulat-ing transactional executions and, second, the methods that

cause reads or writes to the shared states. The correspond-ing representation of the original call graph as depicted inFigure 2(C).

Synchronization specification

These different interpretations of the calling relationshipsare supported in FlexSync through a design process whichwe characterize as a “tagging” process. There are two typesof conceptual tags: the role tag operates on the class levelfor the declaration of the required synchronization facili-ties; the action tag operates on method level for the pro-visioning of these facilities. We use the callgraph to ex-plain the tagging process. However, the use of FlexSyncdoes not require the knowledge of callgraphs. Role tagsand action tags require only local reasoning about a particu-lar type. The tags for specific synchronization mechanismsare as follows:

Lock The tag AutoLckTarget identifies class typesthe methods of which are always synchronized, i.e., havingsynchronized on the method definitions, if Java moni-tor is to be used. The tag LckTarget identifies types thatare caller-synchronized. The methods cause data races aretagged using Guarded. For the call graph given in Fig-ure 2(A), class type D is tagged as an AutoLckTarget ascalls to its methods are unconditionally synchronized. E,F and G, are LckTargets, as they are selectively synchro-nized in the caller’s lexical context. The tagged version ofthe call graph is presented in Figure 3(A).

Block atomicity BAOwner identifies the class types inwhich the executions of one or more of its methods areatomic. We identify these methods with the Atomic-Execution tag. Classes having shared states, in thiscase, are identified with the BATarget tag. We use theAGM (atomic group member) tag on methods defined inBATargets if, first, they cause reads or writes to sharedstates, second, they are in the control flow of Atomic-Executions. In our example (Figure 3(B)), class D hasan atomic method d1. The control flow of d1 includes callsto methods e1, f2 and g1. The control flow informationis maintained behind the scenes by the FlexSync runtime.Therefore, these methods are tagged with AGM and the cor-responding class types E, F and G with AtomTarget.

STM execution Transactional identifies classtypes the states of which require transactional support. Theaccessor methods are identified with AccessorCall7.TXExecution identifies methods to be executed transac-tionally. In our example (Figure 3(C)), AccessorCallidentifies accessor methods c1, e1 and f2. We thus identifytypes C,E, F as Transactional and the transactionalmethod d1 as TXExecution.

7The actual FlexSync APIs distinguish between read tags and writetags. We use a general name, AccessorCall, for the conciseness of thepresentation.

4

Figure 2. Synchronization perspectives of the call graph

Figure 3. Call graph tagging with flex

Implementation of tags

In FlexSync, we use Java interfaces and the AspectJabstract pointcuts to support the concept of tagging.The tagging process can be translated into the program-matic mappings of these interfaces and pointcuts in as-pect modules to the corresponding elements of Java pro-grams. In the AspectJ nomenclature, the mapping of roletags is accomplished declaratively through inter-type decla-rations(ITD) and the actions tags through “concretizing” ab-stract pointcuts. Both techniques are commonly used inaspect library implementations [11, 9, 23]. In the following,we present the reusable logic implemented in FlexSync foreach mechanism, paraphrased using the tag vocabulary:

Lock 1. The executions of the Guarded methods of theAutoLckTargets are protected by the monitor of the cor-responding AutoLckTarget instances. 2. The call sitesof the Guarded methods of the LckOwner are protectedby the monitor of the callee instances of LckOwner.

Atomicity: 1. If a AGM is within the control flow of theAtomicExecution of the BAOwner, acquire the mon-itor lock of its corresponding BATarget and register thelock with the BAOwner. 2. When a AtomicExecutioncompletes, release the monitor locks of all BATargets

registered with the BAOwner.STM: 1. As Transactional instances initialize, set

up their per-instance duplicates, as required by dstm2, toallow state rollbacks. 2. At the call sites of “accessors”8,signal the dstm2 runtime to verify if the on-going trans-action can proceed or must be aborted. 3. Repeat the TXexecution of the TXOwner until the transaction suc-cessfully commits.

We emphasize the fact that the interaction logic can bewell hidden behind our “tag” abstractions and implementedthrough AspectJ. This is a salient property of modular rea-soning as pointed out in [13]. We will not bore the readershere with the implementation details and encourage the in-terested readers to download9 a copy of the library for fur-ther references.

We now come back to the Buffer example presentedin Section 1. The Buffer class contains four methods:setData, getData, isFull, and isEmpty. Thesemethods are invoked by the doWork method of the classBufferUser. Remind that, before invoking the acces-

8Quotation here to entail that, in practice, not all methods that read orwrite the state of the object would lexically start with “set” or “get”.

9FlexSync. URL: http://www.cse.ust.hk/∼charlesz/sync

5

sor methods, the method isFull or isEmpty is called tocheck the state of the buffer. The state is validated againinside the accessor methods. Figure 4 presents the As-pectJ implementation of the three supported synchroniza-tion mechanisms through the FlexSync APIs. The useof the FlexSync tags are underlined with bold italic let-ters. Despite its simplicity, we want to demonstrate thehigh degree of declarativeness in the implementation ofsynchronization enabled by FlexSync. As our evaluationin Section 4 shows, this property still holds for complexJava server systems. The implementation of the copyTomethod is, however, non-declarative and enforced by theAspectJ compiler in the case of the STM support.

Limitations

To use FlexSync, refactoring is still needed to transformblocks into methods. We are currently working on an au-tomated solution to make the process transparent. Thewait/notify semantics are also to be treated case bycase, as they often intertwine with the application logic. Weprovide a replacement of wait by releasing the object lockin the case of BA and using an “abort→re-execution” se-quence in the case of STM. The use of wait, however,will break the atomicity guarantees of BA in general as itsJava semantic mandates the release of the monitor lock. Inaddition, the FlexSync-adaption of the dstm2 library re-quires FlexSync users to manually specify how programstates are duplicated. From our experience, this manual pro-cess can be tedious. Our on-going work is trying to providesimplification solutions. Finally, our lock implementationdoes not handle the use of library-based locks such as theReentrantLock in the Java 5 library, that do not nec-essarily conform to the same lock/unlock interface, hence,require new library code to be created. However, the dom-inating majority of lock uses in the Java programs that wehave studied do not use library locks.

3.3 Global reasoning of tags

The design of synchronization using FlexSync allowsa program to work with multiple synchronization mecha-nisms through configuration. However, when we integratethese programs to build complex systems, we must ensurethe consistent and optimized interactions of locally speci-fied synchronization mechanisms from the global perspec-tive. In FlexSync, the global reasoning is carried out atthe start-up time of Java programs by the FlexSync aspectweaver. Before the first class is loaded for execution, theweaver, as an extended AspectJ bytecode weaver, carriesout static analysis over the bytecode of the entire system tocheck for inconsistencies and optimization opportunities. Italso carries out load-time weaving to specifically treat re-flective loading, a common way of Java composition. We

Figure 4. Implementing synchronization withFlexSync

now present these capabilities in detail.

Lock optimization

A synchronization mechanism is redundant if a type useslock-based tags is never shared among threads in a partic-ular compositional scenario. Such scenarios are often dif-ficult to anticipate from the perspectives of individual pro-grams. The FlexSync load-time weaver first leverage thetechniques of escape analysis [19, 4] to detect, on the per-composition basis, the sharing status for every type asso-ciated with tags. Conventional escape analysis techniquesreason about object instances. Our approach is more con-servative as we define that a type escapes if any of its in-stances escape. Our implementation is based on the Indus

6

project10, which is an enhanced version of the equivalence-class-based analysis [19, 18]. The escape analysis goesthrough all classes seen on the Java class path, and the re-sults are stored in a hash table maintained by the FlexSyncweaver to decided whether the weaving is necessary, if alock-based synchronization mechanism is to be used.

We claim no significant extensions to the Indus escapeanalysis algorithm other than the treatment of reflectiveclass loading. The reflective class loading is referred toas instantiating a class by its lexical name through theClass.forName Java API combined with a type cast. Inthis case, we simply look up all subtypes of the type usedin the type cast and store the results in the mapping table ofthe weaver. The weaver will have the concrete informationafter the actual subtype is loaded.

Consistency checking

Two synchronization mechanisms can cause inconsistencyif, for instance, a type tagged with BATarget is not in thecontrol flow of any atomic blocks, which causes incorrectholding of locks, or, a TXTarget is also tagged separatelywith LckTarget, which violates the lock-free assumptionof STM. To prohibit erroneous usage of tags, FlexSyncuses consistency rules presented in Table 2 as set predi-cates11. These rules enforces the following usages of tags:1. each synchronized type must declare a default synchro-nization mechanism (from rule 1); 2. tags TXTarget andBATarget must not used without the matching “owner”tags (from rule 2); 3. owners or targets tags cannot berepeatedly used on the same type (from rule 3 and 4); 4. theorder in the following tag pairs, (TXOwner, TXTarget)and (BAOwner, BATarget), must be maintained alongthe program control flow with no other “owner” tags usedin between (from rule 5 and 6); 5. lock-based mechanismscannot be in the control flow of STM-based ones (rule 7).

To perform consistency checking, we build a simplecontrol-flow graph consisting of only the tagged types fromthe analysis information collected by the escape analysis ofthe Indus framework. Since the graph is generally small (inthe order of hundreds), a simple depth-first graph traversalcan accomplish the checking of the rules very quickly.

4 Evaluation

The assessment of FlexSync consists of two studies,one related to the programming effort of using FlexSync

10Indus project. URL:http://indus.projects.cis.ksu.edu/

11Note that the control flow definition(cflow) is the conservativecontrol flow computed statically from the bytecode where all possiblebranches of the call flow are explored

in modularizing synchronization, and the other to the func-tional characteristics of FlexSync. The target systems ofstudy is specjbb200512, a popular benchmark for transac-tional enterprise Java applications, OpenJMS13, an opensource implementation of the JMS 1.1 specification, andORBacus14, an open source commercial implementationof the CORBA 2.4 specification. To experiment with soft-ware compositions, we switched the RPC engine of Open-JMS from Java RMI to ORBacus. This is a fully functionalreplacement as verified by the Sonic JMS benchmark15.

4.1 Programming with FlexSync

In this evaluation, we want to first find out if FlexSyncis capable of supporting synchronization in commerciallyused complex systems. We also want to study the pro-gramming characteristics of implementing synchronizationin FlexSync APIs. We first remove the monitor-based syn-chronization from the original implementations. We thenperform necessary refactorings to enclose synchronizationblocks within method definitions. We use FlexSync tosupport the locking, block-level atomicity, and the dstm2-based STM. We cannot use STM on ORBacus becauseORBacus involves network I/O operations which cannothave rollback semantics. This is a typical limitation of STMin general. The OpenJMS server poses the same limita-tions, however, since we use ORBacus as its remote pro-cedure call (RPC) engine, the non-RPC part of the Open-JMS can have STM-compatible behaviors. This is part ofour composition case study which will be presented shortly.

The total size of the FlexSync library is less than 60KBof Java bytecode. The sizes of specjbb2005, ORBa-cus and OpenJMS are listed tn Table 1. In Table 3, wequantify four aspects of the FlexSync-based implementa-tion for each of the studied system: number of moduleswhere synchronization is implemented in the original ap-plication (orig), the number of modules for the FlexSync-based implementation (flex), the total size, in lines of code(LOC), of declarative(dec) and non-declarative(ND) portionin the FlexSync user code, and the non-declarative portionof STM implementation(ND′). We define the declarativedegree, α, as the ratio between the declarative code and thetotal size of synchronization implementation. α′ is com-puted without the STM code. Here we treat the STM asa special case because its non-declarative code almost ex-clusively involves the state duplications, i.e., copying classvariables. We are working on automating this process.

12Specjbb. URL: http://www.spec.org/jbb2005/13OpenJMS URL: http://openjms.sourceforge.net14http://www.iona.com/orbacus15Sonic JMS Benchmark. URL:http://www.sonicsoftware.

com/products/sonicmq/performance benchmarking/index.ssp

7

Definitions Consistency rules1. τ : the type variable. T : the set of all types. 1. pref(τ) := ∅2. tag(τ): the set of tags on τ 2. cflow(τ) ∩ owners := ∅, pref(τ) ∈ {TXTarget, BATarget}3. pref(τ) : tag indicated by design as the preferred tag of τ 3. |tag(τ)| >= 2, tag(τ) ⊆ owners4. cflow(τ): the set of tags in control flows above τ 4. |tag(τ)| >= 2, tag(τ) ⊆ targets5. cover(τi) := {tag(τk)|τk 6= τi, cflow(τk) ∪ tag(τk) 5. cover(τ) := {BAOwner}, pref(τ) ∩ {BATarget} = ∅≡ cflow(τi)} 6. cover(τ) := {TXOwner}, pref(τ) ∩ {TXTarget} = ∅

7.targets := {BATarget, TXTarget, LockTarget, 7. cflow(τ) ∩ {TXOwner, TXTarget} 6= ∅, tag(τ) ∩ {LckTarget,AutoLockTarget} BATarget, AutoLckTarget} 6= ∅8.owners := {BAOwner, TXOwner}

Table 2. Consistency checking rules

The FlexSync-based approach fully exhibits the bene-fit of the aspect oriented approach as, the synchronizationimplementations is not only the much modular (9 mod-ules in FlexSync vs. 37 modules in the original imple-mentations), the task of programming is also simpler fortwo reasons: 1. the coding effort is largely declarative innature, meaning interactions patterns are widely used; 2.the “owner/target” relationship, which is latent and spread-out in conventional implementations, is explicit and localin FlexSync-based approaches, allowing easier reasoningand modification. The declarative degree of ORBacus islow due to the treatments of wait/notify semantics, alimitation we discussed previously.

App Orig flex dec ND ND′ α α′

specjbb 9 3 130 178 168 42% 93%ORBacus 5 2 50 69 36 42% 60%OpenJMS 23 3 313 159 109 66% 86%Total 37 8 493 406 312 55% 84%

Table 3. Static assessment of FlexSync imple-mentations

4.2 Functional characteristics of FlexSync

Performance of FlexSync

For assessing the performance of FlexSync, we use thespecjbb2005 benchmark as an example of stand-aloneJava application. For supporting transactional behaviorsin specjbb, we label the group of class types represent-ing business transactions as TXOwner or BAOwner. Welabel all types declaring synchronized methods withTXTarget or BATarget, respectively. In Figure 5, weplot the benchmark scores16, bops (business operations persecond), against the number of threads.

16All experiments are conducted on a 4-core Intel CPU running 2.6Linux kernels using the JRockit R27 64-bit JVM. Each data point is anaverage of 3 identical runs.

Our first observation from Figure 5 is that, for the lockversion, the FlexSync approach does not incur significantruntime overhead (about 5%). This is generally true in allour experiments as will be shown shortly. The general per-formance profile of specjbb2005 is the same as our mo-tivating buffer example that the lock-based approach givesthe best performance (highest score), followed by BA, thenby STM. The difference is that the BA score is at about30% of that of the lock-based, and the STM version is about20%-25% of the BA version. The reason for this dramaticslowdown is that each specjbb2005 test involves a largeamount of data for which the accesses need to be synchro-nized. As verified by our runtime profiling, in the BA ver-sion, over 20% of the CPU time is spent on lock contentionwhich seriously limit the concurrency of the system. For theSTM version, over 50% of the time is spent on backing upthe data by the dstm2 runtime. The memory requirementfor executing STM on specjbb ranges from 1 to 40 timeslarger as compared to the original version.

This experiment supports our motivation that each syn-chronization mechanism has its unique strengths and weak-nesses. Clear trade-offs exist among properties such as cor-rectness, safety, and performance. The FlexSync approachgives customization options to the users of Java programsand let them decide which properties should take the prece-dence in their application domain.

Case studies of compositions

In this study, we use OpenJMS as an example of com-plex program composed from reusable systems and capableof supporting multiple architectural configurations. Open-JMS uses the remote procedure call (RPC) as its trans-port level mechanism, which is supported by ORBacus,a general purpose RPC middleware. To support the trans-actional and atomic operations, we mark types containssynchronized methods as TXTarget or BATarget,and we make the starting point of RPC invocations in OR-Bacus and of the message dispatching in OpenJMS aswhere the transactional or the atomic executions start.

8

Figure 5. specjbb2005 FlexSync performance

In the first case study, we first gain a general perspectiveof the combinatorial complexity by quantifying all possi-ble choices of synchronization mechanisms in the case ofOpenJMS/ORBacus system. To obtain these points, wemeasure the response time for the JMS server in receiving afixed number of messages into a set of message queues. Wedefine degree of sharing as the average number of clientssharing each message queue. We achieve this by generatingthe client/queue association before each test and hardwiringthe client/queue relationships during the run. We tested 7possible configurations, reported in Figure 6. We make thefollowing observations: 1. the lock version of FlexSyncapproach does not incur overhead as compared to the orig-inal version; 2. multiple synchronization mechanisms cancoexist in providing JMS services; 3. the responses in-volving STM, although oscillating significantly, are fasterthan the lock-versions, which is contradictory to our previ-ous studies; 4. the versions involving BA have the worstperformance compared to other versions. The surprising re-sults about STM is due to the fact that, as each transactionaloperation results from a round of client-server communica-tion, the state duplication in OpenJMS is far less frequentcompared to that of specjbb2005 and our buffer example.In the case of BA, the use of 2PL significantly limits theconcurrent degree of the system, which proves that the de-gree of liveness is vital to the performance of server-typesystems

Our second case study illustrates the scenarios of unan-ticipated compositions and how FlexSync-based synchro-nization understands these cases and achieves performancegains. The canonical concurrency policy used by the Open-JMS/ORBacus system is that each connected client is as-signed a dedicated thread on the server side. Data structuresstoring the RPC targets and the message queues are sharedamong these threads.

Scenario one: Queue dedication If the physical capac-ity allows, the server side can dedicate a separate messag-

Figure 6. Combinatorial synchronization

ing stack for each OpenJMS client simply by publishingeach queue with a unique RPC address. This set-up alonecan improve the processing throughput from 7% to 25% byour measurements. This is unanticipated scenario that canbe achieved purely through deployment configurations. Insuch configurations, since there are no shared states, we cansimply instruct the FlexSync weaver not to weave any syn-chronization mechanisms to achieve further speed-ups.

Scenario two: Event-driven RPC The RPC engine canmake use of the reactor-based [20] event-driven concur-rency models for its capability of handling problems suchas C10k17. Since such models typically make no use ofthreads, the RPC engine serially dispatches requests, ren-dering the thread-safety property of the upper layer mes-saging mechanism in OpenJMS redundant. Again, this isa per-deployment scenario hard to be anticipated by the de-sign of OpenJMS. This scenario can be created by usingthe CAL-based ORBacus implementation from our earlierresearch [23]. The FlexSync sync weaver scans throughthe bytecode image of the entire system and is able to de-tect that all shared states of the messaging layer does notescape from the executing thread of the reactor. Therefore,no synchronization mechanisms are applied as the result.

In Figure 7, we compare the following configurations:the canonical concurrency model (shared original), origi-nal OpenJMS configured to run dedicated queues (dedi-cated original), original OpenJMS using reactor (sharedreactor), dedicated queue using reactor (dedicated reac-tor), and the afore-mentioned two optimized versions us-ing FlexSync (dedicated flex and dedicated reactor flex).Our measurements first justify the validity of the casestudy where queue dedications and the use the reactorcan produce speedups from approximately 7% to 25% at500 clients. In queue dedication scenarios, the FlexSync-

17The C10K problem. http://www.kegel.com/c10k.html

9

optimized version produces 23% speedups compared to theoriginal version. For the use of the single-threaded reac-tor, the FlexSyncversion produces 25% speedups. Thelargest speedup, considering all configurations, is around40%. These measurements prove the functional advantageof FlexSync-based synchronization implementations.

Figure 7. Performance optimization

5 Related Work

As a very active research area, research projects inthe context of lock, atomicity and software transactionalmemory are beyond enumeration. We focus on presentingresearch addressing the programming aspect of synchro-nization challenges. We first covers the aspect orientedapproaches to synchronization. We then present theresearch work on the synthetic approaches for conventionalprogramming languages. We conclude with the discussionon various new language proposals.

AOP implementationsLopes and Lieberherr [15] presented one of the earliestAOP treatments of synchronization using adaptive pro-gramming [14]. In their approach, the structure of a pro-gram and its behavior, including the lock-based synchro-nization, are expressed in separate modules. Code gener-ation is required to produce the final executable system.As a pioneering work, they focused on illustrating a ben-efit of AOP-based synchronization implementation as com-pared to the conventional approach. Our work is built onthese insights and going one step further in considering howdifferent synchronization mechanisms can coexist, be cus-tomized, and interact with the core program consistently incomplex Java systems.

SyncGen [5] focuses on generating synchronizationimplementation from high-level specifications. These

specifications (aspects) are invariant formulae, which aretranslated into byte-code instructions that are inserted into(weaving) the demarcation points of the synchronizedregion. Compared to our approach, aside from the lock-only approach, SyncGen introduce a new programmingparadigm of specifying synchronization in high-level logicformulae. Our approach relies on FlexSync APIs tore-express the synchronization intention, therefore, doesnot fundamentally deviate from how the synchronizationdesign is reasoned conventionally.

Lock synthesisEmmi et al [6] presented an automatic technique that takesa program annotated with atomic sections and producesa lock assignment for global variables that providesatomicity and deadlock free guarantees. Their workprovides evidence that synchronization can be reasonedindependently if we can know the programmers’ intentions,in their case, through annotations. Research such as [4, 2]eliminates unnecessary lock placements through staticanalysis techniques. Our work directly leverages theseresults in performing selective aspect weaving.

Language approachThere have been a proliferation of new language proposals,such as [16, 8, 22, 3] and many others, that provide newlanguage design and the semantic guarantees to help pro-grammers in writing safe, correct, and performant synchro-nization code. Rewriting complex applications with newlanguages is not always straightforward. The majority ofthe language proposals, being focusing on specific synchro-nization mechanisms, also inherit their limitations. We be-lieve that the capability of customization is still a desiredproperty for systems written in these new languages.

6 Conclusion

In the multi-core era, concurrency plays critical roles inimproving software efficiency. The synchronization mech-anisms of reusable Java systems are challenging to buildbecause each of these mechanisms has unique strengthsand weaknesses which are sensitive to specific usage re-quirements. In conventional approaches, synchronizationis reasoned locally within the designed application and in anon-modular way. As a result, applications pay significantperformance costs due to the mismatch between the non-flexibility of the systems and the diversity of deploymentscenarios.

We have presented FlexSync, an aspect oriented syn-chronization library, to alleviate this problem by physi-cally decoupling the synchronization implementation fromthe operational logic of Java systems. This is based onour observation that the design intention of synchroniza-

10

tion and the specific choice of synchronization mechanismscan be explicitly separated and, in practice, most of theintentions can be represented by function-like structures.The FlexSync API fosters the modular reasoning of syn-chronization by essentially enabling programmers to givedifferent interpretations of the same program structure ac-cording to the different synchronization semantics. TheFlexSync library encapsulates reusable logic about howsynchronization mechanisms and the operational logic in-teract. The FlexSync loadtime weaver performs the globalreasoning of synchronization by applying the system-widedeployment-time analysis to achieve consistency and opti-mization.

We evaluated FlexSync with commercially used com-plex Java concurrent systems, and FlexSync is capable ofsupporting the functionalities of these systems. We quantifyboth the programming effort and the functional characteris-tics of FlexSync-based implementations. We found thatprogramming synchronization in FlexSync is commonlydeclarative and specification-like. The FlexSync approachin general does not incur significant runtime overhead. Inaddition, systems using FlexSync also has the capabilityof making customization choices regarding domain-specificor deployment-specific requirements. We showed that, theFlexSyncapproach does not significant incur runtime over-head and can produce speed ups as much as 40% in variousdeployment-time configurations.

As future work, we aim to make programming withFlexSync a lot easier by focus on the automation of in-tention refactoring and state duplication. We also plan tostudy the synergistic effects among customizable concur-rency models [23] and synchronization mechanisms. Ourlong term research goal is to significantly increase the cus-tomization capability of complex systems.

References

[1] Ali-Reza Adl-Tabatabai, Brian T. Lewis, Vijay Menon, Brian R.Murphy, Bratin Saha, and Tatiana Shpeisman. Compiler and run-time support for efficient software transactional memory. In PLDI,pages 26–37, New York, NY, USA, 2006. ACM.

[2] Jonathan Aldrich, Craig Chambers, Emin Gun Sirer, and Susan Eg-gers. Static analyses for eliminating unnecessary synchronizationfrom java programs. In SAS, page pages, 1999.

[3] David F. Bacon, Robert E. Strom, and Ashis Tarafdar. Guava: adialect of java without data races. In OOPSLA, pages 382–400, NewYork, NY, USA, 2000. ACM.

[4] Jong-Deok Choi, Manish Gupta, Mauricio J. Serrano, Vugranam C.Sreedhar, and Samuel P. Midkiff. Stack allocation and synchroniza-tion optimizations for java using escape analysis. ACM TOPLAS,25(6):876–910, 2003.

[5] Xianghua Deng, Matthew B. Dwyer, John Hatcliff, and MasaakiMizuno. Invariant-based specification, synthesis, and verification ofsynchronization in concurrent programs. In ICSE, pages 442–452.ACM Press, 2002.

[6] Michael Emmi, Jeffrey S. Fischer, Ranjit Jhala, and Rupak Majum-dar. Lock allocation. In POPL, pages 291–296, New York, NY, USA,2007. ACM.

[7] Cormac Flanagan and Stephen N Freund. Atomizer: a dynamicatomicity checker for multithreaded programs. In POPL, pages 256–267, New York, NY, USA, 2004. ACM.

[8] Cormac Flanagan and Shaz Qadeer. A type and effect system foratomicity. In PLDI, pages 338–349, New York, NY, USA, 2003.ACM.

[9] Jan Hannemann and Gregor Kiczales. Design Pattern Implementa-tion in Java and AspectJ. In ACM OOPSLA, pages 161–173. ACMPress, 2002.

[10] Maurice Herlihy, Victor Luchangco, and Mark Moir. A flexibleframework for implementing software transactional memory. InOOPSLA, pages 253–262, New York, NY, USA, 2006. ACM.

[11] Elizabeth A. Kendall. Role model designs and implementations withaspect-oriented programming. In ACM OOPSLA, pages 353–369.ACM Press, 1999.

[12] Gregor Kiczales, John Lamping, Anurag Menhdhekar, Chris Maeda,Cristina Lopes, Jean-Marc Loingtier, and John Irwin. Aspect-oriented programming. In Mehmet Aksit and Satoshi Matsuoka, edi-tors, ECOOP, volume 1241, pages 220–242, Berlin, Heidelberg, andNew York, 1997. Springer-Verlag.

[13] Gregor Kiczales and Mira Mezini. Aspect-oriented programmingand modular reasoning. In ICSE, pages 49–58, New York, NY, USA,2005. ACM.

[14] Karl Lieberherr, Doug Orleans, and Johan Ovlinger. Aspect ori-ented programming with adaptive methods. In Communications ofthe ACM, volume 10. ACM, 2001.

[15] Cristina Videira Lopes and Karl J. Lieberherr. Abstracting process-to-function relations in concurrency object-oriented applications. InECOOP, pages 81–99, London, UK, 1994. Springer-Verlag.

[16] Bill McCloskey, Feng Zhou, David Gay, and Eric Brewer. Au-tolocker: synchronization inference for atomic sections. In POPL,pages 346–358, New York, NY, USA, 2006. ACM.

[17] L. Northrop, P. Feiler, R. P. Gabriel, J. Goodenough, R. Linger,T. Longstaff, R. Kazman, M. Klein, D. Schmidt, K. Sullivan, andK. Wallnau. Ultra-Large-Scale Systems: The Software Challenge ofthe Future. Software Engineering Institute, 2006.

[18] Venkatesh Prasad Ranganath and John Hatcliff. Pruning interferenceand ready dependences for slicing concurrent java programs. In CC,pages 39–56. Springer, 2004.

[19] Erik Ruf. Effective synchronization removal for java. In PLDI, pages208–218, New York, NY, USA, 2000. ACM.

[20] Douglas Schmidt, Michael Stal, Hans Rohnert, and FrankBuschmann. Pattern-Oriented Software Architecture Patterns forConcurrent and Networked Objects, volume 2 of Software DesignPatterns. John Wiley & Sons, Ltd, 1 edition, 1999.

[21] Nir Shavit and Dan Touitou. Software transactional memory. InPODC, pages 204–213, New York, NY, USA, 1995. ACM.

[22] Mandana Vaziri, Frank Tip, and Julian Dolby. Associating synchro-nization constraints with data in an object-oriented language. InPOPL, pages 334–345, New York, NY, USA, 2006. ACM.

[23] Charles Zhang and Hans-Arno Jacobsen. Externalizing Java ServerConcurrency with CAL. In ECOOP, pages 362–386. Lecture Notesin Computer Science 5142. Springer, 2008.

11