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

Moved all unused methods to the bottom of the file.

NOT yet ready to DELETE them for 2 reasons:

1) Some code is relevant to Jim's task of finding weakly connected heap groups.
2) If Jim ever decides that a state can have effects that go deeper than just 1 level (i.e. if we have effects that tell us that we can visit a.b.c without changing states), then we'd need to use the code to generate traversal graphs before printing. They've already been modified to (mostly) work with states, but just have a few small bugs from me changing other parts of the code.

Changed a lot of things in RCR. It works for the most part (manually inspected with the state diagram from the power benchmark). There are minor issues with the printout such as empty { } and nothing being inlined since the refCount for states seems to NOT work. Also, there seems to be states with empty effects... which is weird. The major issue is that the buildcode has problems interfacing with the new code. Some problems, not even Jim could figure them out.

bug fix

bug fixes...

bug fixes

Bug fixes in MGC verison. SPECjbb2005 is now working with 62-core gc.

Jim told me to do this...

changed options in code to actually print reach states on genreach output graphs

a bug, fix it later

cc paper example, THERE IS A BUG

bug fix

bug fixes

small bug

fix mistake....allocnodes are like disjoint heapregionnodes...
create new class allocsitenode which is like allocsite from disjointness...
hacked rcr file so it would compile with this change..unclear if it will work correctly

changes to give compiler run times for phases....

change so that new analysis runs for all benchmarks

bug fix on the glb function of the lattice + working on the checking with the composite lattice

Work in progress... I need to rework how to handle the case if we have more than 1 starting location for each state.

Here's a TODO list for things out of my control:
1) Need total number of independent heaproots (for hashtable creation).
2) Need to be able to get connected component ID (heaproot ID) from current state.
3) Need to get to get Demsky's Pointer Analysis Graph (and someone should check the way I used it is correct, see createTraversalGraph and addToTraversalGraphStartingAt)
4) Fix the way BuildCodeOoOJavaCode gets a weakmap on line 1822
5) Need a list a list of Allocs that have transitions leading into them per state (needed to know where to start traversal from a transitioned-to state.)
6) See TODOs in SMFEState.java

don't need to do pointer analysis in Main

fixing bugs...

Updated hashRCR and Queue_RCR to conform with new standards (i.e. storing both a ptr and a state). Fixed a bug in Queue_RCR where the first dequeue is a null.... Don't know how that could have been overlooked for so long and not cause an error...

changes.