fix: handle the case that TASK doesn't have any heap conflicts

changes

changed number of RCR workers to matchooo workers. The new speed up is either 13x or 6x...... 13x is running the single version but for some odd reason, it garbage collects... the 6x comes from running the rcrpointer version with depth of 0 which SHOULD call no traverser and spawn no sese (other than the parent).

I think it could be faster still, but a bug in the conflict graph is preventing me from adding more seses to speed things up.

voronoi benchmark. On dc-11, the computation part runs 3x faster with a computation depth of 3.

It could probably do better but for some reason, when I add another sese (see Vertex.java line 115 where it's commented out), RuntimeConflictResolver.java crashes on line 506 (cannot find a conflict graph for a given sese).

fixes -nostalltr flag: if it is valid to prune heap examiners, turning off both of task & stallsite examiners

Enable 1,2,4,8,16,32,50 cores' execution

TODO: move record pool to a thread-local thing and never deallocate it.  Issue is that a child can retire, then its parent, then deallocate the child's entire mem pool... then the child's traverser finally gets around to the record

bug fix, at task exit we are looking for sources that cause virtual read of soemthing the task wrote, don't just look at parent and siblings, but also the parent's parent and the parent's sibling, etc.

change on the labyrinth run script: making memory interleaved on all cpus as like other runscripts

hack seems to help a little...power isn't going to have good performance...

D2 bug

fix SOR bug

bug and remove debug code

get back some of the speed we are losing from bug fixes...

bug fix...wasn't adding out of context nodes that get summarized to set of ndoes that exist in context...

change benchmark to run once, not up to seven times

alter benchmark to run once, not up to seven times

get debug statements out of single version

Changes

bug fix...things are slower to compile...:(

bug fix for refCount in SMFEStates. I'm not sure if this fix covers all cases (it seems like it should to me)...

bug fix

bug fix and other change

checked in new version of bm

bug fix, have to dereference this pointer

changes.

changes: handle the case that there is only one work item after enqueue, then it reports nothing and makes the worker steal from other queues.

bug fix...code that was never exercised...

static initializers cause a problem for DFJ, easy enough to work around them

version of delaunay that has a spin bug

get this debug print out of here

gc bug fix

bug fix...

updates.

at task exit, a task should acquire any out-set variables that arent already it the task record.  These could be from static or dynamic sources, so some extra analysis info should be saved to generate the correct copy statements.  make sure static and dynamic tracking variables are generated too

speculative version of delaunay works single-threaded just fine

changes on run scripts

dfj version of delaunay refinement executes the original algorithm with workers=1, but set to 2 another malformed triangle appears...

#ifdef this out if not threads

bug fix on the oooJava queue: when tries to add a vector item, get rid of finished item in front of it.

keep a copy of the original delaunay refinement algorithm for comparison, and dfj version is crashing on nodes (triangles) with zero neighbors, but original configured graphs are the same size...

lock bug for gc...jin, make sure tilera gc doesn't have same bug...need to update thread lock pointer to locks at end of gc

bug fixes

bug...

ugle hacks to get around compiler bugss...

bugs in buildflat...break optimization phase

changes: build conflict graphs that have line number information of stall sites

similar bugs to rcr

reworking parallel implementation, both single and DFJ runs build a zero-node configuration right now, whoops

Add a warning when a method call does not resolve to a defined method

changes

changes to get pass specJBB validation

specjbb build on intel now...

add wait/notify

change

change

add ieeeremainder

make this work with MGC

fix array

small bug

add enwmethos

changes for correctness

trying to build specjbb on intel

changes

fixed benchmark

really, really nasty bug...see page 8-9 of vol 3A of intel processor manual for x86 memory reordering...

new information...x86 allows reads to be reordered with earlier writes to different locations....

add mbarrier for situations where we can't allow this to happen...

missing barrier

bug fix

stuff for running set up

modified algorithm for dfj style parallelism

static variables now actually work...we don't want static variables here i think though...

add RCR to the global gc initializer...bad if we have globals though

Bug fixes and add some code for easy debugging

bug fix for yeom...can you try to see if power works now?

build pruned graphs that encode conflict information...
double periphery nodes may contain conflicts...conflict effects are put in brackets...
edges that have conflicts are dashed

These are the files that were giving me trouble last night. The single version runs fine, the rcr version errors out (either it's a RCR build problem, an RCR runtime error, or it screws with the data of the actual program and causes it to error out at Cavity.build...). This may indicate that there's something wrong with our runtime...

make hashCode a native method for java lang Object...

move hashCode method to native method

bug fix for stephen

only print out line numbers in debug mode

bring last changes before executing benchmakrs

changes: reorganizes debug messages

add a new compiler flag -nolock: turning off synchronization lock

changes for better debug messages

changes.

Added in semi-trivial locations (to test it). However, can't confirm results because the old make rcr takes a while (I didn't let it finish, but it was over 5 mins...) and the new one crashes with a NULLPOINTEREXCEPTION

Tried to squeeze out more performance by changing the LinkedLIsts in the Delaunay port to vectors (which is closer to the original implementation of ArrayLists). Seems not to make an appreciable difference though...

Added Vector.clone() and VectorIterator

Bug fix: should use unsigned int instead of int for pointers in shared heap. Also as we now use a big share array to hold mapping information, do not need to allocate extra memory for master core's local heap.

changes: only apply the variable analysis on the method containing TASK

change

Added manual invocation of garbage collector via System.gc()

Optimized HashMap/HashSet and added System.gc() for manual garbage collection invokation

Changes/optimizations to benchmark.

change due to changes of math class library

bug fixes on OoOJava, now it works fine with all of benchmarks(but, Kmeans has lower speedup 10.6x than 13.8x. still working on...)
-changes on the potential stall site analysis: propagating the status of callee's return node to the caller region and when current node has a status change, making following nodes updated to get a new potential stall site status.
-changes on liveness analysis of OoOJava: new analysis only covers the task region, not whole region of the flat method.
-changes on disjoint analysis: rather than using reachgraph's inAccessibleSet, using the result of brian's new accessible analysis.

The benchmark works as far as I can tell (passes internal tests). We just need to put in sese blocks now if that's the case.

... There are things preventing me from doing a precise check.
1) It appears that given the same input and everything, the while loop will inevitably run a different number of times for each run (this occurs in both the original and ported code) and pick a different order of triangles to process.
2) The differences in how we and Java handle collection/sets gives a different ordering of which triangles we process (which affects which triangles become bad at the end).

Aside from that, there seems to be some performance issues.
1) It seems that the original code benefits from branch prediction as successive, duplicate runs (inherent in the benchmark) yields faster and faster timings. Our run-time stays the same in successive runs. This is true even though the number of triangles processed stays relatively close to each other.
2) When processing the large.2 files (about 10k triangles), the difference between our first runtime and the original code's runtime is within 100ms of each other (out of roughly 1000ms), which sounds reasonable (note that on successive runs, the original code speeds up by a factor of 1.6).  However when we process the massive.2 files (roughly 100k triangles), our runtimes are double the original code's runtime (but successive runs of the original code yields a speedup of only 1.12. Whatever speedup it got on the large.2 file is amortized). Also, our ported code garbage collects and then crashes (out of memory) on the second run (there are 3 repeated runs).

This is as much as I can do at the moment, going to need some guidance on the performance issues mentioned above and also where to place the sese blocks.

It compiles and runs now... but it doesn't appear to be doing the right thing... It passes internal verification but appears to be taking fewer iterations than the original program...

Compiles with a few warnings... Doesn't run yet though.

Added an error case