Alchemist: A Transparent Dependence Distance Profiling Infrastructure

Xiangyu Zhang, Armand Navabi and Suresh JagannathanDepartment of Computer Science

Purdue University, West lafayette, Indiana, 47907{xyzhang,anavabi,suresh}@cs.purdue.edu

Abstract—Effectively migrating sequential applications totake advantage of parallelism available on multicore platformsis a well-recognized challenge. This paper addresses importantaspects of this issue by proposing a novel profiling technique toautomatically detect available concurrency in C programs. Theprofiler, called Alchemist, operates completely transparentlyto applications, and identifies constructs at various levels ofgranularity (e.g., loops, procedures, and conditional statements)as candidates for asynchronous execution. Various dependencesincluding read-after-write (RAW), write-after-read (WAR), andwrite-after-write (WAW), are detected between a construct andits continuation, the execution following the completion of theconstruct. The time-ordered distance between program pointsforming a dependence gives a measure of the effectivenessof parallelizing that construct, as well as identifying thetransformations necessary to facilitate such parallelization.Using the notion of post-dominance, our profiling algorithmbuilds an execution index tree at run-time. This tree is usedto differentiate among multiple instances of the same staticconstruct, and leads to improved accuracy in the computedprofile, useful to better identify constructs that are amenableto parallelization. Performance results indicate that the pro-files generated by Alchemist pinpoint strong candidates forparallelization, and can help significantly ease the burden ofapplication migration to multicore environments.

Keywords-profiling; program dependence; parallelization;execution indexing

I. I NTRODUCTION

The emergence of multicore architectures has now madeit possible to express large-scale parallelism on the desktop.Migrating existing sequential applications to this platformremains a significant challenge, however.Determining coderegions that are amenable for parallelization, and injectingappropriate concurrency control into programs to ensuresafetyare the two major issues that must be addressed byany program transformation mechanism. Assuming that coderegions amenable for parallelization have been identified,techniques built upon transactional or speculation machin-ery [24], [25], [7] can be used to guarantee that concurrentoperations performed by these regions which potentiallymanipulate shared data in ways that are inconsistent withthe program’s sequential semantics can be safely revoked.By requiring the runtime to detect and remedy dependencyviolations, these approaches free the programmer from ex-plicitly weaving a complex concurrency control protocolwithin the application.

Identifying code regions where concurrent execution canbe profitably exploited remains an issue. In general, the bur-den of determining the parts of a computation best suited forparallelization still falls onto the programmer. Poor choicescan lead to poor performance. Consider a call to procedurep that is chosen for concurrent execution with its callingcontext. If operations inp share significant dependencieswith operations in the call’s continuation (the computationfollowing the call), performance gains that may accrue fromexecuting the call concurrently would be limited by theneed to guarantee that these dependencies are preserved. Thechallenge becomes even more severe if we wish to extractdata parallelism to allow different instances of a code regionoperating on disjoint memory blocks to execute concurrently.Compared to function parallelism, which allows multiplecode regions to perform different operations on the samememory block, data parallelism is often not as readilyidentifiable because different memory blocks at runtimeusually are mapped to the same abstract locations at compiletime. Static disambiguation has been used with success tosome extent through data dependence analysis in the contextof loops, resulting in automatic techniques that parallelizeloop iterations. However, extracting data parallelism forgeneral programs with complex control flow and dataflowmechanisms, remains an open challenge.

To mitigate this problem, many existing parallelizationtools are equipped with profiling components. POSH [17]profiles the benefits of running a loop or a procedure asspeculative threads by emulating the effects of concurrentexecution, squashing and prefetching when dependencies areviolated. MIN-CUT [14] identifies code regions that can runspeculatively on CMPs by profiling the number of depen-dence edges that cross a program point. TEST [5] profiles theminimum dependence distance between speculative threads.In [23], dependence frequencies are profiled for criticalregions and used as an estimation of available concurrency.Dependences are profiled at the level of execution phases toguide behavior-oriented parallelization in [7].

In this paper, we present Alchemist, a novel profilingsystem for parallelization, that is distinguished from theseefforts in four important respects:

1) Generality.We assumeno specific underlying runtimeexecution model such as transactional memory to dealwith dependency violations. Instead, Alchemist pro-

vides direct guidance for safe manual transformationsto break the dependencies it identifies.

2) Transparency.Alchemist considers all aggregate pro-gram constructs (e.g., procedures, conditionals, loops,etc.) as candidates for parallelization with no need forprogrammer involvement to identify plausible choices.The capability of profiling all constructs is importantbecause useful parallelism can be sometimes extractedeven from code regions that are not frequently exe-cuted.

3) Precision. Most dependence profilers attribute de-pendence information to syntactic artifacts such asstatements without distinguishing the context in whicha dependence is exercised. For example, althoughsuch techniques may be able to tell that there is adependence between statementsx andy inside a loopin a function foo(), and the frequency of the depen-dence, they usually are unable to determine if thesedependences occur within the same loop iteration,cross the loop boundary but not different invocationsof foo(), or cross both the loop boundary and themethod boundary. Observe that in the first case, theloop body is amenable to parallelization. In the secondcase, the method is amenable to paralelization. Bybeing able to distinguish among these different formsof dependence, Alchemist is able to provide a moreaccurate characterization of parallelism opportunitieswithin the program than would otherwise be possible.

4) Usability. Alchemist produces a ranked list of con-structs and an estimated measure on the work neces-sary to parallelize them by gathering and analyzingprofile runs. The basic idea is to profile dependencedistances for a construct, which are the time spansof dependence edges between the construct and itscontinuation. A construct with all its dependencedistances larger than its duration is amenable forparallelization. The output produced by Alchemistprovides clear guidance to programmers on both thepotential benefits of parallelizing a given construct,and the associated overheads of transformations thatenable such parallelization.

The paper makes the following contributions:

• Alchemist is a novel transparent profiling infrastructurethat given a C or C++ program and its input, producesa list of program points denoting constructs that arelikely candidates for parallelization. Alchemist treatsany program construct as a potential parallelizationcandidate. The implication of such generality is that adetected dependence may affect the profiles of multipleconstructs, some of whom may have already completedexecution. A more significant challenge is to distinguishamong the various dynamic nesting structures in whicha dependence occurs to provide more accurate and

richer profiles. We devise a sophisticated online algo-rithm that relies on building an index tree on programexecution to maintain profile history. More specifically,we utilize a post-dominance analysis to construct a treeat runtime that reflects the hierarchical nesting structureof individual execution points and constructs.

• Alchemist supports profiling of Read-After-Write(RAW) dependences as well as Write-After-Write(WAW) and Write-After-Read (WAR) ones. RAW de-pendencies provide a measure of the amount of avail-able concurrency in a program that can be exploitedwithout code transformations, while removing WARand WAW dependencies typically require source-levelchanges, such as making private copies of data.

• We evaluate profile quality on a set of programs thathave been parallelized elsewhere. We compare theprogram points highly ranked by Alchemist with thoseactually parallelized, and observe strong correlationbetween the two. Using Alchemist, we also manuallyparallelize a set of benchmarks to quantify its benefits.Our experience shows that, with the help of Alchemist,parallelizing medium-size C programs (on the orderof 10K lines of code) can lead to notable runtimeimprovement on multicore platforms.

II. OVERVIEW

Our profiling technique detects code structures that can berun asynchronously within their dynamic context. More pre-cisely, as illustrated in Fig. 1, it identifies code structures likeC, delimited byCentry and Cexit, which can be spawnedas a thread and run simultaneously withC ’s continuation,the execution following the completion ofC. C can bea procedure, loop, or anif-then-else construct. Ourexecution model thus follows the parallelization strategyavailable usingfutures [10], [15], [25] that has been usedto introduce asynchronous execution into sequential Java,Scheme and Lisp programs; it is also similar to the behavior-oriented execution model [7] proposed for C. A futurejoinswith its continuation at a claim point, the point at which thereturn value of the future is needed.

Our goal is to automatically identify constructs that areamenable forfuture annotation and provide direct guidancefor the parallelization transformation. The basic idea is toprofile the duration of a construct and the time intervalsof the two conflicting memory references involved in anydependence from inside the construct to its continuation.Consider the sequential run in Fig. 1. Assume our profilingmechanism reveals a dependence between execution pointsx

andy. The duration of constructC and the interval betweenx andy are profiled asTdur andTdep, respectively. Let thetimestamps of an execution points in the sequential and theparallel executions betseq(s) and tpar(s), respectively; theinterval betweenx andy in the parallel run is then

Tdur

Tdep

Sequential

Parallel

Centry

x

Cexit y

y

x

Tdep-Tdur

Centry Cexit

Ccontinuation

Ccontinuation

Figure 1. Overview (the dashed lines represent the correspondence between execution points).

8471

8472

1600

…

1662

1662

6629

1701

1704

8527

int zip (in, out)

{

while (/* input buffer not empty*/) {

/* process one literal at a time*/

if (/*processing buffer full*/)

flush_block (&window[],…);

flag_buf[last_flags++]=… ;

}

… = flush_block (&window[],…);

outbuf[outcnt++]= /*checksum*/

}

off_t flush_block (buf, len, …)

{

flag_buf[last_flags] = /*the current flag*/;

input_len + = /* length of the block*/;

/* Encode literals to bits*/

do {

… flag =flag_buf[…];

if (flag … ) {

if (bi_valid > …) {

outbuf[outcnt++]=(char) bi_buf…;

bi_buf= /* encoding*/;

bi_valid + = … ;

}

}

} while (/*not the last literal*/);

last_flags=0;

/* Write out remaining bits*/

outbuf[outcnt++]=(char) bi_buf…;

return /* # of compressed literals*/;

}

6496

6495

6505

6528

6670

6671

6673

754

756

757

758

759

6698

6064

…

790

6597

Source PositionSource Position

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

21.

22.

23.

24.

25.

26.

27.

28.

29.

Profile

1. Method main Tdur=20432742, inst=1

2. Loop (main,3404) Tdur=20431181, inst=1

… …

9. Method flush_block Tdur=643408, inst=2

RAW: line 29 → line 9 Tdep=1

RAW: line 28 → line 10 Tdep=3

RAW: line 14 → line 14 Tdep=4541215

RAW: line 22 → line 19 Tdep=4541231

… …

Figure 2. Profilinggzip-1.3.5.

tpar(y) − tpar(x)= (tseq(y) − (tseq(Cexit) − tseq(Centry))) − tseq(x)= (tseq(y) − tseq(x)) − (tseq(Cexit) − tseq(Centry))= Tdep − Tdur

as shown in Fig. 1.

The profile and the dependence types provide guidance toprogrammers as follows.

• For RAW dependences, i.e.,x is a write andy is aread of the same location, ifTdep > Tdur, constructC is a candidate for asynchronous evaluation with itscontinuation. That is because it indicates the distancebetweenx andy is positive in the parallel run, meaningit is highly likely that wheny is reached,C has alreadyfinished the computation atx and thus dependence canbe easily respected. A simple parallelization transfor-

mation is to annotateC as a future, which is joinedat any possible conflicting reads e.g.,y. More complextransformations that inject barriers which stall the readat y until it is guaranteed thatC will perform no furtherwrites to the same location (e.g.,x has completed) arealso possible.

• For WAR dependences, i.e.,x is a read andy is a write,if C has been decided by the RAW profile to be par-allelizable, two possible transformations are suggestedto the programmer. The first one is for dependenceswith Tdep < Tdur, which implies that if the constructis run asynchronously, the write may happen beforethe read and thus the read may see a value from itslogical future, violating an obvious safety property.Therefore, the programmer should create a private copyof the conflict variable inC. For dependences withTdep > Tdur, the programmer can choose to join the

asynchronous execution beforey.• WAW dependences are similar to WAR.Consider the example in Fig. 2, which is abstracted from

the single file version ofgzip-1.3.5 [1]. It contains twomethodszip andflush_block. To simplify the presen-tation, we inline methods called by these two proceduresand do not show statements irrelevant to our discussion.The positions of the statements in the source that are shownin the code snippet are listed on the right. Procedurezipcompresses one input file at a time. It contains awhile loopthat processes the input literals, calculating the frequenciesof individual substrings and storing literals into temporarybuffers. Whenever these buffers reach their limits, it callsprocedureflush_block to encode the literals and emitthe compressed results at line 6. During processing, thewhile loop setsflags[] which will be used later duringencoding. The procedureflush_block first records thecurrent flag and updates the number of processed inputsat lines 13-14; it scans the input buffer within the loop atlines 16-25, encodes a literal into bits stored within bufferbi_buf, which is eventually output to bufferoutbufat line 20. Variablebi_valid maintains the number ofresult bits in the buffer, andoutcnt keeps track of thecurrent pointer in the output buffer. After all the literalsareprocessed, the procedure resets thelast_flags variableat line 26 and emits the remaining bits in the bit buffer. Notethat at line 20 in the encoding loop, bits are stored to theoutput buffer at the unit of bytes and thus at the end, thereare often trailing bits remaining. The number of compressedliterals is returned at line 29.

The code in Fig. 2 is significantly simplified from theactual program, which is comprised of much more complexcontrol flow and data flow, both further confounded byaliasing. It is difficult for traditional static techniquestoidentify the places where concurrency can be exploited.Runninggzip with Alchemist produces the results shownin Fig. 2. Each row corresponds to a source code construct.The profile containsTdur, approximated by the number ofinstructions executed inside the construct and the numberof executions of the construct. For example, the first rowshows that themain function executes roughly 20 millioninstructions once. The second row shows that the loopheaded by line 3404 in the original source executes roughly20 million instructions once, i.e. there is one iteration oftheloop.

Let us focus on the third row, which corresponds to theexecution of calls to procedureflush_block. From theprofile, we see the procedure is called two times – the firstcall corresponds to the invocation at line 6, and the other atline 9. Some of the profiled RAW dependences between theprocedure and its continuation are listed. Note that while onedependence edge can be exercised multiple times, the profileshows the minimalTdep because it bounds the concurrencythat one can exploit. We can see that only the first two (out

of a total of fifteen) dependences, highlighted by the box,do not satisfy the conditionTdep > Tdur, and thus hinderconcurrent execution. Further inspection shows that the firstdependence only occurs between the call site at line 9, whichis out of the main loop inzip(), and the return at 29. Inother words, this dependence does not prevent the call at 6from being spawned as a future. The second dependenceis between the write tooutcnt at 28 and the read at10. Again, this dependence only occurs when the call ismade at line 9. While these dependencies prevent the call toflush_block on line 9 from running concurrently withits continuation (the write tooutbuf), it does not addressthe calls toflush_block made at line 6. Because thesecalls occur within the loop, safety of their asynchronousexecution is predicated on the absence of dependenceswithin concurrent executions of the procedure itself, as wellas the absence of dependencies with operations performedby the outer procedure. Snippets of the profile show that theoperation performed at line 14 has a dependence with itselfseparated by an interval comprising roughly 4M instructions.Observe that the duration of the loop itself is only 2Minstructions, with the remaining 2M instructions comprisedof actions performed within the iteration after the call. Alsoobserve that there is no return value from calls performedwithin the loop, and thus dependencies induced by suchreturns found at line 9, are not problematic here.

Method flush_block Tdur=643408, inst=2

WAW: line 28 → line 10 Tdep=7

WAR: line 17 → line 7 Tdep=6702

WAR: line 26 → line 7 Tdep=6703

WAR: line 17 → line 13 Tdep=3915860

… …

Figure 3. WAR and WAW profile.

Besides RAW dependencies, Alchemist also profiles WARand WAW dependencies. Unlike a RAW dependence whichcan be broken by blocking execution of the read access untilthe last write in the future upon which it depends completes,WAR and WAW dependencies typically require manifestcode transformations. The WAR and WAW profile forgzipis shown in Fig. 3. The interesting dependences, namelythose which do not satisfyTdep > Tdur, are highlighted inthe box. The first dependence is between the two writesto outcnt at 28 and 10. Note that there are no WAWdependences detected between writes tooutbuf as theywrite to disjoint locations. Another way of understanding itis that the conflict is reflected on the buffer indexoutcntinstead of the buffer itself. As before, this dependence doesnot compromise the potential for executing calls initiatedat 6 asynchronously. The second dependence is causedbecause the read toflag_buf[] happens at 17 andthe write happens later at 7. While we might be able to

inject barriers between these two operations to prevent adependence violation, a code transformation that privatizesflag_buf[] by copying its values to a local array isa feasible alternative. Similarly, we can satisfy the thirddependence by hoisting the reset oflast_flags frominside flush_block () and put it in the beginningof the continuation, say, between lines 6 and 7. In themeantime, we need to create a local copy oflast_flagsfor flush_block(). While the decision to inject barriersor perform code transformations demands a certain degree ofprogrammer involvement, Alchemist helps identify programregions where these decisions need to be made, alongwith supporting evidence to help with the decision-makingprocess. Of course, as with any profiling technique, thecompleteness of the dependencies identified by Alchemistis a function of the test inputs used to run the profiler.

void A ( ) {

s1;

B ( );

}

void B( ) {

s2;

}

1.

2.

3.

4.

5.

6.

7.

void C ( ) {

if (…) {

s3;

if (…)

s4;

}

}

1.

2.

3.

4.

5.

6.

7.

1.

2.

3.

4.

5.

6.

7.

void D ( ) {

while (…) {

s5;

while (…)

s4;

}

}

2 3 6 2 3 4 5 2 3 4 5 4 5 4 2

A

B

2 3 6

C

2

4

2 3 4 5

code

Trace

Index

(a) (b) (c)

D

2

4 4

2 3 4 5 4 5 4 2

Figure 4. Execution Indexing Examples.

III. T HE PROFILING ALGORITHM

Most traditional profiling techniques simply aggreate in-formation according to static artifacts such as instructionsand functions. Unfortunately, such a strategy is not adequatefor dependence profiling. Consider the example trace inFig. 4 (c). Assume a dependence is detected between thesecond instance of 5 in the trace and the second instanceof 2. Simply recording the time interval between the twoinstances or increasing a frequency counter is not sufficientto decide available concurrency. We need to know that thedependence indeed crossed the iteration boundaries of loops2 and 4. This information is relevant to determine if theiterations of these loops are amenable for parallelization. Incontrast, it is an intra-construct dependence for procedureD and can be ignored if we wish to evaluate calls toDconcurrently with other actions. Thus, an exercised depen-dence edge, which is detected between two instructions, hasvarious implications for the profiles of multiple constructs.The online algorithm has to efficiently address this issue.

A. Execution Indexing

RAW, WAR, and WAW dependences are detected betweenindividual instructions at run time. Since our goal is toidentify available concurrency between constructs and theirfutures, intra-construct dependences can be safely discarded.An executed instruction often belongs to multiple constructsat the same time. As a result, a dependence may appear asan intra-construct dependence for some constructs, and as across-boundary dependence for others.

In order to efficiently update the profile of multiple con-structs upon detection of a dependence, we adopt a techniquecalled execution indexing[26] to create an execution indextree that represents the nesting structure of an executionpoint. Fig. 4 shows three examples of execution indexing.In example (a), nodeA denotes the construct of procedureA. As statements 2 and 3 are nested in procedureA, theyare children of nodeA in the index tree. ProcedureB isalso nested inA. Statement 6 is nested inB. The indexfor an execution point is the path from the root to thepoint, which illustrates the nesting structure of the point.For example, the index of the first instance of statement 6in trace (a) is[A,B]. Fig. 4 (b) shows an example for anif-then-else construct. The construct led by statement2 is nested in procedureC(), and construct 4 is nestedwithin construct 2, resulting in the index tree in the figure.Note that statement 2 is not a child of node 2, but a childof nodeC because it is considered as being nested in theprocedure instead of the construct led by itself. Example(c) shows how to index loops. Since loop iterations areoften strong candidates for parallelization, each iterationis considered as an instance of the loop construct so thata dependence between iterations is considered as a crossboundary dependence and hence should be profiled. We cansee in the index tree of example (c), the two iterations ofloop 4 are siblings nested in the first iteration of 2. Theindex of52 (the second instance of statement 5) is[D, 2, 4],exactly disclosing its nesting structure. From these examples,we observe that (i) a dynamic instance of a construct isrepresented by a subtree; (ii) the index for a particularexecution point is the path from the root to this point.

While Fig. 4 only shows simple cases, realistic appli-cations may include control structures such asbreak,continue, return, or evenlong_jump/ set_jump;a naive solution based on the syntax of the source codewould fail to correctly index these structures. Control flowanalysis is required to solve the problem. The intuition isthat a construct is started by a predicate and terminatedby the immediate post-dominator of the predicate. Similarto calling contexts, constructs never overlap. Therefore,asimilar stack structure can be used to maintain the currentindex of an execution point. More precisely, a push isperformed upon the execution of a predicate, indicating thestart of a construct. A pop is performed upon the execution

of the immediate post-dominator of the top construct on thestack, marking the end of that construct. The state of thestack is indeed the index for the current execution point.

Rule Event Instrumentation(1) Enter procedureX IDS.push(X)(2) Exit procedureX IDS.pop()(3) Non-loop predicate atp IDS.push(p)(4) Loop predicate atp if (p==IDS.top()) IDS.pop();

IDS.push(p)(5) Statements while (p=IDS.top()∧ s is the immediate

post-dominator ofp) IDS.pop()*IDS is the indexing stack.

Figure 5. Instrumentation Rules for Indexing.

The instrumentation rules for execution indexing are pre-sented in Fig. 5. The first two rules mark the start andend of a procedure construct by pushing and popping theentry associated with the procedure. In rule (3), an entry ispushed if the predicate is not a loop predicate. Otherwise inrule (4), the top entry is popped if the entry corresponds tothe loop predicate of the previous iteration, and the currentloop predicate is then pushed. Although rule (4) pushes andpops the same value, it is not redundant as these operationshave side effects, which will be explained next. By doing so,we avoid introducing a nesting relation between iterations.Finally, if the top stack entry is a predicate and the currentstatement is the predicate’s immediate post-dominator, thetop entry is popped (Rule 5). Irregular control flows such asthose caused bylong_jump andset_jump are handledin the same way as that presented in [26].

Managing the Index Tree for an Entire Execution.Unfortunately, the above stack-based method that is similarto the one proposed in [26] only generates the index for thecurrent execution point, which is the state of the index stack.It does not explicitly construct the whole tree. However, inAlchemist, we need the tree because a detected dependencemay involve a construct that completed earlier. For instance,assume in the execution trace of Fig. 4 (c), a dependence isdetected between51 and22. The index of51 is [D, 2, 4]. Itis nested in the first iteration of loop 4, which has completedbefore22, and thus its index is no longer maintained by thestack. In order to update the right profiles,51’s index needsto be maintained.

A simple solution is to maintain the tree for the entireexecution. However, doing so is prohitively expensive andunnecessary. The key observation is that if a constructinstanceC has ended for a period longer thanTdur(C),the duration of the construct instance, it is safe to removethe instance from the index tree. The reason is that anydependence between a point inC and a future point, mustsatisfy Tdep > Tdur(C) and hence does not affect theprofiling result. The implication is that the index tree can bemanaged by using a construct pool, which only maintainsthe construct instances that need to be indexed. Since onenode is created for one construct instance regardless of

Table IThe Algorithm for Managing the Index Tree.

pc is the program counter of the head of the construct.PROFILE constrains the profile for constructs, indexed bypc.pool is the construct pool.

1: IDS.push (pc)2: {3: c=pool .head();4: while (timestamp − c.Texit < c.Texit − c.Tenter) {5: c=pool .next();6: }7: pool .remove(c);8: c.label= pc;9: c.Tenter= timestamp;

10: c.Texit= 0;11: c.parent= IDS[top-1];12: IDS[top++]=c;13: }14:15: IDS.pop ()16: {17: c=IDS[−− top];18: c.Texit=timestamp;19: pc=c.label;20: PROFILE[pc].Ttotal+=c.Texit-c.Tenter;21: PROFILE[pc].inst++;22: pool .append(c)23: }

the Tdur of the construct, only those constructs that getrepeatedly executed have many instances at runtime and posechallenges to index tree management.

Theorem 1:Assume the maximum size of an instanceof a repeatedly executed construct isM , a statement canserve as the immediate post-dominator for a maximum ofN

constructs, and the maximum nesting level isL. The memoryrequirement of Alchemist isO(M · N + L).

Proof: Let i be the instruction count of an executionpoint, constructs completed beforei−M are of no interestbecause any dependence betweeni and any point in thoseconstructs must haveTdep > M . Thus, only constructs thatcompleted betweeni − M and i need to be indexed withrespect toi, i.e., the nodes for those constructs can notbe retired. As the maximum number of constructs that cancomplete in one execution step isN according to rule (5) inFig. 5, the number of constructs completed in that durationcan not exceedM ·N . SinceL is the maximum number ofactive constructs, i.e., constructs that have not terminated,the space complexity isO(M · N + L).

The theorem says that the memory requirement of Al-chemist is bounded if the size of any repeatedly executedconstruct is bounded. In our experiment, a pre-allocated poolof the size of one million dynamic constructs never led tomemory exhaustion. The pseudo-code for the algorithm ispresented in Table I. It consists of two functions:IDS.pushandIDS.pop. In the instrumentation rules presented earlier,they are the push and pop operations of the index stack.

In the algorithm, variablepool denotes the construct pool.Upon calling the push operation with the program counterof the head instruction of a construct, usually a predicate ora function entry, the algorithm finds the first available con-struct from the pool by testing if it satisfies the condition atline 4. Variabletimestamp denotes the current time stamp.It is simulated by the number of executed instructions. If thepredicate is true,c can not be retired and the next constructfrom pool is tested. The first construct that can be safelyretired is reused to store information for the newly enteredconstruct. Lines 8-11 initialize the construct structurec.Specifically, line 11 establishes the connection fromc toits enclosing construct, which is the top construct on thestack. Line 12 pushesc to the stack.

Upon calling the pop function, the top construct is popped.Its ending time stamp is recorded at line 18. The profile ofthe popped construct, indexed by its pc in thePROFILEarray, is updated. The total number of executed instructionsfor the construct is incremented by the duration of thecompleted instance. Note that a construct may be executedmultiple times during execution. The number of executedinstances of the construct is incremented by one. Finally, thedata structure assigned to the completed construct instanceis appended to the construct pool so that it might bereused later on. We adopt a lazy retiring strategy – a newlycompleted construct is attached to the tail of the pool whilereuse is tried from the head. Hence, the time a completedconstruct remains accessible is maximized.

B. The Profiling Algorithm

Functionprofile() in Table II explains the profilingprocedure. The algorithm takes as input a dependence edgedenoted as a tuple of six elements. The basic rule is toupdate the profile of each nesting construct bottom up fromthe enclosing construct of the dependence head up to thefirst active (not yet completed) construct along the head’sindex. This is reflected in lines 7 and 14. The conditionat 7 dictates that a nesting construct, if subject to update,must have completed (c.Tenter < c.Texit

1) and must notretire. If a construct has not completed, the dependence mustbe an intra-dependence for this construct and its nestingancestors. If the construct has retired and its residencememory spacec has been reused, it must be true thatTh

falls out of the duration of the current construct occupyingc and thus condition at 7 is not true. Lines 8-13 are devotedto updating the profile. It first tests if the dependence hasbeen recorded. If not, it is simply added to the construct’sprofile. If so, a further test to determine if theTdep of thedetected dependence is smaller than the recorded minimumTdep is performed. If yes, the minimumTdep is updated.

To illustrate the profiling algorithm, consider the exampletrace and its index in Fig. 4 (c). Assume a dependence is

1Texit is reset upon entering a construct.

Table IIProfiling Algorithm.

pch andpct are the program counters for the headand tail of the dependence.

ch, ct are the construct instances in which the headand tail reside.

Th, Tt are the timestamps.1: Profile(pch, ch, Th, pct, ct, Tt)2: {3: Tdep=Tt-Th;4: pc=ch.label;5: P=PROFILE[pc];6: c=ch;7: while (c.Tenter <= Th < c.Texit) {8: if (P .hasEdge (pch → pct) {9: Tmin=P .getTdep (pch → pct);

10: if (Tmin > Tdep)11: P .setTdep (pch → pct, Tdep);12: } else13: P .addEdge (pch → pct, Tdep);14: c=c.parent;15: }16: }

detected between52, with index[D, 2, 4], and22, with index[D]. The input toprofile is the tuple< pch = 5, ch =4r, Th = 6, pct = 2, ct = D, Tt = 8 >, in whichn represents a construct headed byn. 4r represents thenode 4 on the right. The algorithm starts from the enclosingconstruct of the head, which is4r. As Tenter(4r) = 6 andTexit(4r) = 7, the condition at line 7 in Table II is satisfiedas Th = 6; the profile is thus updated by adding the edgeto PROFILE[4]. The algorithm traverses one level up andlooks at 4r ’s parent 2. The condition is satisfied again asTenter(2) = 2 < Th = 6 < Texit(2) = 8; thus, thedependence is added toPROFILE[2], indicating that it isalso an external dependence for2, which is the first iterationof the outer while loop in code Fig 4(c). However, the parentconstructD is still active withTexit = 0; thus, the conditionis not satisfied here andPROFILE[1] is not updated.

Recursion. The algorithm in Table I produces incorrect in-formation in the presence of recursion. The problem residesat line 20, where the total number of executed instructions ofthe construct is updated. Assume a functionf() calls itselfand results in the index path of[f1, f2]. Here we use thesubscripts to distinguish the two construct instances. Uponthe end off1 and f2, Tdur(f1) andTdur(f2) are aggregatedto PROFILE[f ].Ttotal. However, asf2 is nested inf1, thevalue ofTdur(f2) has already been aggregated toTdur(f1),and thus is mistakenly added twice to theTtotal. The solutionis to use a nesting counter for each pc so that the profile isaggregated only when the counter reaches zero.

Inadequacy of Context Sensitivity.In some of the recentwork [6], [8], context sensitive profiling [2] is used tocollect dependence information for parallelization. However,

context sensitivity is not sufficient in general. Consider thefollowing code snippet.

F() {for (i...)

for (j...)A();B();

}}

}

Assume there are four dependences between some execu-tion insideA() and some execution insideB(). The firstone is within the samej iteration; the second one crossesthe j loop but is within the samei iteration; the thirdone crosses thei loop but is within the same invocationto F(); the fourth one crosses different calls toF(). Theyhave different implications for parallelization. For instance,in case one, thej loop can be parallelized; in case two, thei loop can be parallelized but thej loop may not; and soon. In all the four cases, the calling context is the same. Incase four, even using a loop iteration vector [6] does nothelp.

IV. EXPERIMENTATION

Alchemist is implemented on valgrind-2.2.0 [19]. Theevaluation consists of various sequential benchmarks. Someof them have been considered in previous work and others(to the best of our knowledge) have not. Relevant detailsabout the benchmarks are shown in Table III and discussedbelow.

Table IIIBENCHMARKS, NUMBER OF STATIC/DYNAMIC CONSTRUCTS AND

RUNNING TIMES GIVEN IN SECONDS.

Benchmark LOC Static Dynamic Orig. Prof.197.parser 11K 603 31,763,541 1.22 279.5bzip2 7K 157 134,832 1.39 990.8gzip-1.3.5 8K 100 570,897 1.06 280.4130.li 15K 190 13,772,859 0.12 28.8ogg 58K 466 4,173,029 0.30 70.7aes 1K 11 2850 0.001 0.396par2 13K 125 4437 1.95 324.0delaunay 2K 111 14,307,332 0.81 266.3

A. Runtime

The first experiment is to collect the runtime overhead ofAlchemist. The performance data is collected on a PentiumDual Core 3.2 GHZ machine with 2GB RAM equipped withLinux Gentoo 3.4.5. The results are presented in Table III.ColumnsStatic and Dynamic present the number ofstatic and dynamic constructs profiled. ColumnOrig.presents the raw execution time. ColumnProf. presentsthe times for running the programs in Alchemist. The

slow down factor ranges from 166-712 due to dependencedetection and indexing. Note that the valgrind infrastructureitself incurs 5-10 times slowdown. The numbers of staticunique constructs and their dynamic instances are presentedin the third column of Table III. According to the profilingalgorithm mentioned earlier, profile is collected per dynamicconstruct instance and then aggregated when the constructinstance is retired. As mentioned earlier, we used a fix-sizedconstruct pool so that the memory overhead is bounded. Thepool size is one million, with each construct entry in thepool taking 132 bytes. We have not encountered overflowwith such a setting. Since Alchemist is intended to be usedas an offline tool, we believe this overhead is acceptable.Using a better infrastructure such as Pin [18] may improveruntime performance by a factor of 5-8, and implementingthe optimizations for indexing as described in [26] may leadto another 2-3 factor improvement.

B. Profile Quality

The next set of experiments are devoted to evaluating pro-file quality. To measure the quality of the profiles generatedby Alchemist we run two sets of experiments. For the firstset of experiments, we consider sequential programs thathave been parallelized in previous work. We observe howparallelization is reflected in the profile. We also evaluatethe effectiveness of Alchemist in guiding the parallelizationprocess by observing the dependences demonstrated bythe profile and relating them to the code transformationsthat were required in the parallelization of the sequentialprograms. Furthermore, we run Alchemist on a sequentialprogram that can not be migrated to a parallel version tosee if the profile successfully shows that the program is notamenable for parallelization.

For our other set of experiments, we parallelize variousprograms using the output from Alchemist. We first runthe sequential version of the program through Alchemistto collect profiles. We then look for large constructs withfew violating static RAW dependences and try to parallelizethose constructs. To do so, we use the WAW and WARprofiles as hints for where to insert variable privatizationand thread synchronization between concurrently executingconstructs in the parallel implementation. We assume nospecific runtime support and parallelize programs usingPOSIX threads (pthreads).

1) Parallelized Programs:We first consider programsparallelized in previous work. We claim that a given con-struct C is amenable for asynchronous evaluation if 1)the construct is large enough to benefit from concurrentexecution and 2) the interval between its RAW depen-dences are greater than the duration ofC. To verify ourhypothesis we examined programsgzip, 197.parserand130.lispparallelized in [7]. The programs were parallelizedby marking possibly parallel regions in the code and then

(a) Gzip Profile 1 (b) Gzip Profile 2 (c) 197.parser Profile (d) 130.lisp Profile

Figure 6. Size and number of violating static RAW dependencesfor constructs parallelized in [7]. For Figures 6(a) and 6(b), parallelized constructsC1 andC9 represent a loop on line 3404 andflush_block, respectively. Forgzip, Fig. 6(b) shows the constructs that remain afterC1 and all nested constructswith a single instance per instance ofC1 have been removed. ConstructC3 in Fig. 6(c) represents the parallelized loop on line 1302 in197.parserandconstructC2 in Fig. 6(d) represents the parallelized loop on line 63 in130.lisp.

running in a runtime system that executes the marked regionsspeculatively.

Fig. 6 shows the profile information collected by Al-chemist for the sequential versions ofgzip, 197.parserand130.lisp. The figure shows the number of instructions (i.e.total duration) and the number of violating static RAWdependences for the constructs that took the most time ineach program. The duration of the constructs are normalizedto the total number of instructions executed by the program,and the number of violating static RAW dependences arenormalized to the total number of violating static RAWdependences detected in the profiled execution. Intuitively,a construct is a good candidate if it has many instructionsand few violating dependences.

Gzip v1.3.5. The loop on line 3404 and theflush_block procedure were parallelized in [7]. In Fig-ures 6(a) and 6(b) constructC1 represents the loop andC9 representsflush_block. The figure clearly showsthat C1 is a good candidate for concurrent execution be-cause it is the largest construct and has very few violat-ing RAW depedences. ParallelizingC1 makes constructsC2, C3, C4, C5, andC8 no longer amenable to paralleliza-tion because the constructs only have a single nested instancefor each instance ofC1. In other words, the constructsare parallelized too as a result ofC1 being parallelized.Thus, to identify more constructs amenable for asynchronousexecution, we removed constructsC1, C2, C3, C4, C5, andC8. The remaining constructs are shown in Fig. 6(b).ConstructsC9, C10 and C11 have the fewest violationsout of the remaining constructs, and the largest con-structC9 (flush_block) becomes the next parallelizationcandidate. The Alchemist WAW/WAR profile pinpointedthe conflicts betweenunsigned short out_buf andint outcnt andunsigned short bi_buf andintbi_valid that were mentioned in [7].

197.parser. Parser has also been parallelized in [7].

Fig. 6(c) presents the profile information. ConstructC3corresponds to the loop (on line 1302) which was par-allelized. Inspection of the code revealed that constructsC1 and C2 (corresponding respectively to the loop inread_dictionary and methodread_entry), whileboth larger thanC3 and with less violating dependences,were unable to be parallelized because they were I/O bound.

130.lisp.XLisp from Spec95, also parallelized by [7], is asmall implementation of lisp with object-oriented program-ming. It contains two control loops. One reads expressionsfrom the terminal and the other performs batch processingon files. In the parallel version, they marked the batch loopas a potentially parallel construct to run speculatively intheirruntime system. ConstructC2 in Fig.6(d) corresponds to thebatch loop inmain. C1 corresponds to methodxlloadwhich is called once before the batch loop, and then a singletime for each iteration of the loop. The reasonC1 executedslightly more instructions thanC2 was because of the initialcall before the loop. Thus parallelizing constructC2, as wasdone in the previous work, results in all but one of the callsto xlload to be executed in parallel.

Delaunay Mesh Refinement.It is known that paral-lelizing the sequential Delaunay mesh refinement algorithmis extremely hard [16]. The result of Alchemist providesconfirmation. In particular, most computation intensive con-structs have more than 100 static violating RAW depen-dences. In fact, the construct with the largest number ofexecuted instructions has 720 RAW dependences.

2) Parallelization Experience:For the following bench-marks, we have used profiles generated by Alchemist to im-plement parallel versions of sequential programs. We reportour experience using Alchemist to identify opportunities forparallelization and to provide guidance in the parallelizationprocess. We also report speedups achieved by the parallelversion on 2 dual-core 1.8GHZ AMD Opteron(tm) 865processors with 32GB of RAM running Linux kernel version

2.6.9-34.

Table IVPARALLELIZATION EXPERIENCE:THE PLACES THAT WE PARALLELIZED

AND THEIR PROFILES.

Progam Code Location Static ConflictRAW WAW WAR

bzip2 6932 in main() 3 103 05340 in compressStream() 23 53 63

ogg 802 in main() 6 30 17aes 855 in AES ctr128 encrypt 0 7 3par2 887 in Par2Creator:: 1 12 19par2 ProcessData ()

489 in Par2Creator:: 0 2 12OpenSourceFiles()

Par2cmdline. Par2cmdline is a utility to create andrepair data files using Reed Solomon coding. The orig-inal program was 13718 lines of C++ code. We gener-ated a profile in Alchemist by runningpar2 to createan archive for four text files. By looking at the pro-file we were able to parallelize the loop at line 489 inPar2Creator::OpenSourceFiles and the loop atline 887 in Par2Creator::ProcessData. The loopat line 489 was the second largest construct and only hadone violating static RAW dependence. The Alchemist profiledetected a conflict when a file is closed. The parallel versionmoved file closing to guarantee all threads are completebefore closing files. The loop at line 887 was the eighthlargest construct with no violating static RAW dependencesand thus is the second most beneficial place to performparallelization. The loop processes each output block. Weparallelized this loop by evenly distributing the processingof the output blocks among threads. We ran the parallelversion and the sequential version on the same large 42.5MBWAV file to create an archive. The parallel version took 6.33seconds compared to the sequential version which completedin 11.25 seconds (speedup of 1.78).

Bzip2 v1.0.Bzip2takes one or more files and compresseseach file separately. We ranbzip2in Alchemist on two smalltext files to generate profiling information. With the guidanceof the Alchemist profile, we were able to write a parallelversion ofbzip2 that achieves near linear speedup. The firstconstruct we were able to parallelize was a loop inmainthat iterates over the files to be compressed. This was thesingle largest construct in the profile and had only 3 violatingdependences. The WAW dependences shown in the profileindicate a naive parallelization would conflict on the sharedBZFILE *bzf structure and the data structures reachablefrom bzf such asstream. In the sequential program, thisglobal data structure is used to keep track of the file handle,current input buffer and output stream. When parallelizingbzip2 to compress multiple files concurrently each threadhas a thread localBZFILE structure to operate on.

After parallelizing the first construct we removed it from

the profile along with all nested constructs with only a singleinstance per iteration of the loop, as we did in Fig. 6(b)with gzip. From the new constructs Alchemist identifiedthe opportunity to compress multiple blocks of a singlefile in parallel, although the construct had an unusuallyhigh number of violating static RAW dependences. Furtherinspection showed the RAW dependences identified by theprofile resulted from a call toBZ2_bzWriteClose64after the loop. Each iteration of the loop compresses 5000byte blocks and if there is any data that is left overafter the last 5000 byte block,BZ2_bzWriteClose64processes that data and flushes the output file. As withthe loop in main, the profile reported many WAW andWAR dependences on thebzf structure. By examining theviolating dependences reported by Alchemist, we were ableto rewrite the sequential program so that multiple blockscould be compressed in parallel. The parallelization processincluded privatizing parts of the data in thebzf structureto avoid the reported conflicts. The parallel version ofbzip2achieves near-linear speedup both for compressing multiplefiles and compressing a single file. We compressed two42.5MB wav files with the original sequentialbzip2and ourparallel version with 4 threads. The sequential version took40.92 seconds and the parallel version took 11.82 secondsresulting in a speedup of 3.46.

AES Encryption (Counter Mode) in OpenSSL.AES isa block cipher algorithm which can be used in many differentmodes. We extracted the AES counter mode implementationfrom OpenSSL. Based on the profile generated by Alchemistwhile encrypting a message of size 512 (32 blocks each128 bits long) we parallelized the implementation. Theencryption algorithm loops over the input until it has read inan entire block and then callsAES_encrypt to encrypt theblock and then makes a call toAES_ctr128_inc(ivec)to increment theivec. The incrementedivec is then usedby the next call toAES_encrypt to encrypt the next block.We parallelized the main loop that iterates over the input(sixth largest construct), which had no violating static RAWdependences in the profile. The WAW/WAR dependencesin the profile included conflicts onivec. In our parallel

Table VPARALLELIZATION RESULTS.

Benchmark Seq.(sec.) Par. (sec.) Speedupbzip2 40.92 11.82 3.46ogg 136.27 34.46 3.95par2 11.25 6.33 1.78aes ctr 9.46 5.81 1.63

version each thread has its ownivec and must compute itsvalue before starting encryption.

To evaluate the performance of our parallel encryptionimplementation we encrypted a message that had 10 millionblocks. Each block in AES is 128 bits. We executed on 4

threads. The sequential encryption took 9.46 seconds and theparallel encryption took 5.81 seconds resulting in a speedupof 1.63.

Oggenc-1.0.1.Oggencis a command-line encoding toolfor Ogg Vorbis, a lossy audio compression scheme. Theversion we use contains 58417 lines of code. We ranoggencin Alchemist on two small WAV files each about 16KBand used the profile to parallelize the program. The largestconstruct identifies the main loop that iterates over the twofiles being encoded. The profile identifies 6 violating staticRAW dependences. Among the detected violations for theloop is a dependence on theerrors flag that identifiesif an error occurred in encoding any of the files. There arealso conflicts on a variable used to keep track of the samplesread. We parallelized the loop with POSIX threads so thatmultiple files can be encoded in parallel. Each thread hasa localerrors flag that keeps track of whether or not anerror occurred in the encoding of its file. Every thread alsohas a local count of samples read. Our parallel version ofoggenctakes as long as the most time consuming file. Ourparallel version uses 4 threads. We used the parallel versionto encode 4 large WAV files. As expected the parallel versionachieved nearly linear speedup (3.95) with the sequentialversion taking 136.27 seconds and the parallel version taking34.46 seconds.

V. RELATED WORK

Profiling For Concurrency. Many existing program par-allelization projects have profiling as an essential compo-nent. This is because statically identifying available par-allelism, especially data parallelism, is hard. TEST[5] isa hardware profiler for decomposing java programs intospeculative threads. It focuses on decompositions formedfrom loops. It profiles the minimum dependence distancebetween loop iterations and uses that to guide thread-level speculation (TLS). Compared to TEST, Alchemist isa software profiler that targets C programs and is moregeneral since it does not rely on TLS to remedy WARand WAW dependencies at runtime, but rather providesfeedback to the programmer who can then perform necessarycode transformation to resolve these dependencies, and ittreats any program construct as a potential parallelizationcandidate. POSH [17] is another TLS compiler that exploitsprogram structure. It considers loop iterations and theircontinuations, subroutines and their continuations as thecandidates for speculative thread composition. It modelsthe effects of concurrent execution, thread squashing, andprefetching that closely simulate program execution underTLS. POSH is capable of profiling various constructs, whichis similar to Alchemist. However, as the profiling algorithmis not explained in detail, it is not clear how the authors han-dle the problem of updating profiles for nesting constructsupon detecting dependences. Furthermore, like TEST, WAWand WAR dependences are not profiled. Behavior oriented

parallelization [7] is a technique that supports speculativelyexecuting regions of sequential programs. It includes aprofiler that detects dependences between execution phases.A transaction-based mechanism is employed to supportspeculation. In [23], Praunet al. analyze parallelizationopportunities by quantifying dependences among criticalsections as a density computed over the number of executedinstructions. Their work collects profile for critical regionsguarded by synchronization or constructs annotated by pro-grammers as candidates for speculative execution. Notably,their task level density profile does not provide directguidance for programmers. ParaMeter [20] is an interactiveprogram analysis and visualization system for large tracesto facilitate parallelization. It features fast trace compressionand visualization by using BDD. In comparison, Alchemistis a profiler that does not record the whole trace. It wouldbe interesting to see if indexing can be integrated withParaMeter to present a hierarchical view of traces. Recently,context sensitive dependence profiling is used for speculativeoptimization and parallelization in [6], [8]. However contextsensitivity is not adequate to model loop carry dependences.In comparison, the novelty of Alchemist lies in using indextrees to provide more fine-grained information.

Program Parallelization. Traditional automatic programparallelization exploits concurrency across loop iterationsusing array dependence analyses [3], [9]. In programs whichexhibit more complex dataflow and control-flow mecha-nisms, these techniques are not likely to be as effective.Parallelizing general sequential programs in the presenceofside-effects has been explored in the context of the Jadeparallel programming language [21]. A Jade programmer isresponsible for delimiting code fragments (tasks) that couldbe executed concurrently and explicitly specifying invariantsdescribing how different tasks access shared data. The run-time system is then responsible for exploiting availableconcurrency and verifying data access invariants in orderto preserve the semantics of the serial program. Recently,speculative parallel execution was shown to be achievablethrough thread level speculation [17], [14], [22], [28]. Thesetechniques speculatively execute concurrent threads and re-voke execution in the presence of conflicts. Software trans-actional memory (STM) [13], [11], [12] ensures serializableexecution of concurrent threads. Kulkarniet. al [16] presenttheir experience in parallelizing two large-scale irregularapplications using speculative parallelization. Bridgeset.al [4] show that by using a combination of compiler andarchitectural techniques, one can effectively parallelize alarge pool of SPEC benchmarks.

Our work is also related to context-sensitive profiling [2],in which simple performance measurements are associatedwith calling contexts. Alchemist demands more fine-grainedcontext information. Central to Alchemist’s design is thechallenging issue of managing index trees. The uniquecharateristics of dependence, e.g., it is a two-tuple relation,

also distinguishes our design. The concept offorward con-trol dependence graph(FCDG) proposed by Sarkar [29] forthe purpose of parallelization is similar to our indexing tree.The difference is that indexing tree is dynamic and FCDGis static.

VI. CONCLUSION

This paper describes Alchemist, a novel dependence pro-filing infrastructure. Alchemist istransparent, and treats anyprogram construct as a potential candidate for paralleliza-tion. Dependence profile for all constructs can be collectedby one run using execution indexing technique. Alchemistis general, as it does not rely on any specialized hardwareor software system support. We argue Alchemist isusefulbecause it provides direct guidance for programmers toperform parallelization transformation. Experimental resultsshow that Alchemist provides high quality information tofacilitate parallelization with acceptable profiling overhead.

REFERENCES

[1] http://people.csail.mit.edu/smcc/projects/single-file-programs/.

[2] G. Ammons and T. Ball and J. R. Larus. Exploiting hardwareperformance counters with flow and context sensitive profiling.In PLDI’97, pages 85–96.

[3] D. F. Bacon, S. L. Graham, and O. J. Sharp. Compiler trans-formations for high-performance computing.ACM ComputingSurveys, 26(4), pages 345–420, 1994.

[4] M. Bridges, N. Vachharajani, Y. Zhang, T. Jablin, and D.August. Revisiting the sequential programming model formulti-core. InMICRO ’07, pages 69–84.

[5] M. Chen and K. Olukotun. Test: A tracer for extractingspeculative threads. InCGO ’03, pages 301–312.

[6] T. Chen, J. Lin, X. Dai, W.C. Hsu, and P.C. Yew. DataDependence Profiling for Speculative Optimization. InCC’04,pages 57–72.

[7] C. Ding, X. Shen, K. Kelsey, C. Tice, R. Huang, and C. Zhang.Software Behavior Oriented Parallelization. InPLDI’07, pages223–234, San Diego, CA.

[8] K.F. Faxen, K. Popov, L. Albertsson, S. Janson. Embla - DataDependence Profiling for Parallel Programming In CISIS’08,pages 780–785.

[9] M. W. Hall, B. R. Murphy, S. P. Amarasinghe, S. Liao, andM. S. Lam. Interprocedural Analysis for Parallelization. InLCPC’06, pages 61–80.

[10] R. Halstead. Multilisp: A Language for Concurrent SymbolicComputation.TOPLAS, 7(4):pages 501–538, 1985.

[11] T. Harris and K. Fraser. Language Support for LightweightTransactions. InOOPSLA’03, pages 388–402.

[12] M. Herlihy, V. Luchangco, M. Moir, and W. N. Scherer,III. Software Transactional Memory for Dynamic-Sized DataStructures. InPODC’03, pages 92–101.

[13] M. Herlihy and E. B. Moss. Transactional memory: architec-tural support for lock-free data structures. InISCA’93, pages289–300.

[14] T. A. Johnson, R. Eigenmann, and T. N. Vijaykumar. Min-cut Program Decomposition for Thread-Level Speculation. InPLDI’04, pages 59–70.

[15] R. Kelsey, W. Clinger, and J. Rees. Revised5 Report on theAlgorithmic Language Scheme.Higher-Order and SymbolicComputation, 11(3):pages 7–105, 1998.

[16] M. Kulkarni, K. Pingali, B. Walter, G. Ramanarayanan,K. Bala, and L. P. Chew. Optimistic Parallelism RequiresAbstractions. InPLDI’07, pages 211–222.

[17] W. Liu, J. Tuck, L. Ceze, W. Ahn, K. Strauss, J. Renau, andJ. Torrellas. POSH: A TLS Compiler that Exploits ProgramStructure. InPPOPP’06, pages 158–167.

[18] C. Luk, R. Cohn, R. Muth, H. Patil, A. Klauser, G. Lowney, S.Wallace, V. Reddi and K. Hazelwood. Pin: building customizedprogram analysis tools with dynamic instrumentation. InPLDI’05, pages 190-200.

[19] N. Nethercote and J. Seward. Valgrind: A framework forheavyweight dynamic binary instrumentation. InPLDI ’07,pages 89–100.

[20] G. D. Price, J. Giacomoni, and M. Vachharajani. VisualizingPotential Parallelism in Sequential Programs. InPACT ’08,pages 82–90.

[21] M. C. Rinard, D. J. Scales, and M. S. Lam. Jade: A High-Level, Machine-Independent Language for Parallel Program-ming. IEEE Computer, 26(6):pages 28–38, 1993.

[22] J. Greggory Steffan, C. B. Colohan, A. Zhai, and T. C. Mowry.A Scalable Approach to Thread-Level Speculation. InISCA’00,pages 1–12.

[23] C. v. Praun, R. Bordawekar, and C. Cascaval. Modelingoptimistic concurrency using quantitative dependence analysis.In PPoPP ’08, pages 185–196.

[24] C. v. Praun, L. Ceze, and C. Cascaval. Implicit parallelismwith ordered transactions. InPPOPP’07, pages 79–89.

[25] A. Welc, S. Jagannathan, and A. Hosking. Safe futures forJava. InOOPSLA’05, pages 439–453.

[26] B. Xin, N. Sumner, and X. Zhang. Efficient program execu-tion indexing. InPLDI ’08, pages 238–248.

[27] J. Hardwick. Implementation and Evaluation of an EfficientParallel Delaunay Triangulation Algorithm. InSPAA’97, pages23–25.

[28] L. Rauchwerger Y. Zhan and J. Torrellas. Hardware forSpeculative Run-Time Parallelization in Distributed Shared-Memory Multiprocessors. InHPCA’98, pages 162–173.

[29] V. Sarkar. Automatic partitioning of a program dependencegraph into parallel tasks. In IBM Journal of Research andDevelopment, pages 779–804, 1991.