split garbage collector into three files...

simplify the gc code...

bug...wonder how this used to work??

changes.

more bug fixes

changes

code to generate calls into JNI native code...

changes

more changes

more

Change the implementation of classobj

changes

templates towards jni

extends the grammar to have a way to define a new type of location that is allowed to have spinning values

move hashcode into header...part of prep to switch class libraries

add hashcode field

change

changes

make compiler work on mac...

move up initializethreads

missing changes

make work on mac

change

changes.

bug fix for optimizations`

changes.

thread id should be an int

bug

changes

remove lockcount

changes.

good for a little more speedup...

improve specjbb marks...rework locks a little...

bug fixes

change

changes

bug fixes

bug fix

get specjbb compiling again...get rid of annoying warnings...still left with large long warning..unclear of what to do..

checkin to only generate C for callable methods...
use javacallgraph when appropriate
get rid of some annoying warnings

having better speedup

adjust run configurations

change...

obligatory ascii art

detect possibly evil tasks and do the right thing if a possibly evil execution pattern is detected

an example of an evil task

commit the temporarily abandoned version of Delaunay refinement

having working version of both single and rcrpointer. currently it's working fine with original benchmark size 64k points which seems to be realllllllllly small for our env)

Added the Generic N-Tuple capability. Main File is MultiHash which uses Tuples interface file and Tuple to get the job done. OptimizedView is a single view of one of the tables.

having a verification routine.

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