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

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