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

Shouldn't have been checked in the first place... accident.

Remove the local mapping tbl and shared mapping tbl in gc, instead, use a big shared array to hold the mapping information of moved objs

Closer to compiling. at the moment, it throws a NullPointerException right after the output Build class:LinkedList. Not sure what's going on there.

clean up math.java a little...standardize things to the actual Java class library...plus i didn't like having more ifs than needed

Added min/max for long

Changed LinkedList to return a boolean instead of crashing when an object isn't found in the remove method.

These are the Delaunay Refinement files with the generics removed. It was a bit tedious, so I'm uploading now so we'd have a restart point if something goes wrong.

more bug fixes

memory leaks for rentry

make compile

bug fixes

changes

bug fix...

have to treat reads of inaccessible variables that are the last node specially...

changes...

another bug fix...need to visit everything once also..

could infinite loop under some cases...think this fixes the bug and cleans up the logic a little

bug fix

bug fix on RBlockRelationAnalysis: found that status changes of potential stall site is not propagated properly. now, OoOJava works fine with Power benchmark.

more bug fixes

Bug fix in MGC version: bamboo_threadlocks is also a Runtime reference that should be checked and flushed during GC

bug fix

hacks to improve speed...including turning off debugging

changes

bug fix

add support for super calls...ie...super.foo()

fix various runtime bugs...most benchmarks running under rcr now

changes.

bug fixes

bug fix..

define bool

changes

bug fix

bug fix

typo

changes

changes

try to get runtimeconflictresolver working...and cleaning up the code...

changes to process/prune state machines

class to prune/process state machines

add lookup tables for effects

changes on ssjava.

Bug fix...supposed to pass in bsm into Pointer analysis...

initial taint should have null whereDefined so we don't get fake cycles

Bug fixes for gc

get rid of length field....

Bug fixes for gc

Bug fix