Integration of LICM in Deuce STM

The LICM (lightweight identification of captured memory) is a new lightweight
runtime technique to identify captured memory, for which no STM barriers are
needed.  Captured memory corresponds to memory allocated inside a transaction
that cannot escape (i.e., is captured by) its allocating transaction.
This technique requires two new features that were not available in the Deuce
STM: 1) enhance the object model with transactional metadata; 2) additional
filtering to the standard behavior of the STM barriers.
These two features are included without any change or extension to the Deuce API
and guarantying retro-compatibility with existing STMs implementations for
Deuce. Moreover, it is possible to enhance any existing STM with the LICM
without requiring either its recompilation or any modification to its
source-code.

* ClassEnhancer => new interface that specifies additional transformations to
the standard Deuce instrumentation.

* ClassEnhancerChain => implements a chain of transformations. This solution is
a modified version of the Decorator design pattern, because we need to
instantiate a new ClassEnhancer for each instrumentation.

* Agent => support for ClassEnhancer objects, which act like ASM transformations
that can be included after the standard instrumentation made by the DeuceStm to
transactional classes. These enhancers are initialized through the value of the
system property org.deuce.transform.post.

* CapturedState => the top of the transactional classes hierarchy, which
replaces the Object class.

* ClassEnhancerCapturedState and ClassEnhancerCapturedStateArray => responsible
for enhancing all transactional classes with the captured state infrastructure.

* Modifications to ContextDelegator class => the constant
CONTEXT_DELEGATOR_INTERNAL may be initialized through the value of the system
property  org.deuce.delegator and the thread local the Context object may be
wrapped in a chain of context filters specified by the system property
org.deuce.transaction.filter.

* ContextDelegatorCapturedState => the new delegator that performs the LICM and
can replace the standard ContextDelegator. This delegator depends of the
filtering capability provided by the ContextFilterCapturedState and the
ClassEnhancerCapturedState.
Unit Tests to validate the LICM support in Deuce

Include new unit tests to evaluate the consistency of the LICM (lightweight
identification of captured memory). Furthermore, and according to the original
configuration provided in the original build.xml for the target Test, all the
java RT classes were being excluded from Deuce instrumentation. This resulted
from the default behavior of Deuce, which excludes all the JAVA RT classes,
except if the end-user programmer explicitly specifies a different Exclude
system property.
Yet, in many benchmarks, such as the StmBench7, we cannot exclude the JAVA RT
from instrumentation, because we need the transactional version of some of the
java.util data structures. So it makes sense that the consistency of Deuce STM
to be validated with unit tests that include the instrumented version of the
JAVA RT.
For this purpose we changed the build.xml ANT script that performs the unit
tests.

* There is a new section in the build.xml with three different ways to
instrument the Java RT: 1) the original Deuce instrumentation, which produces
the lib/rt-deuce.jar; 2) with the capture analysis support, but excluding
arrays: lib/rt-deuce-capmem.jar; 3) with the capture analysis support for all
kinds of objects including arrays: lib/rt-deuce-capmem-full.jar;

* The target junits of the build.xml includes the following new
parameterization:

   1. the system property org.deuce.exclude to excludes some immutable classes;

   2. the xbootclasspath to the instrumented version of the Java RT;

   3. the delegator responsible for the capture analysis;

   4. the logging properties.

* New package org.deuce.utest.capmem with the unit tests specifically to
evaluate the LICM mechanism.

* Due to LICM requirements there are minor changes to some existing unit tests.
One of those changes (in the classes AbortTest, SerialTest and UnsafewTest) is
related to the replacement of the top of the classes' hierarchy from Object to
CapturedState, which is being avoided by JUnit classes when performed with ANT,
because the Junit is loaded before running the Deuce instrumentation.
Include the JWormBench in the benchmarks package
Merge remote branch 'fmc/feature/capture-analysis' into develop
Fixes to STAMP Benchmarks

* genome.Genome => one of the worker threads was running in the main thread,
which was replaced by a new thread similar to the others. Furthermore, the
await() condition through the genome.Barrier object was replaced by the join()
to each worker thread.

* genome.Sequencer => the empty version of the atomicMethodFive was replaced by
the atomicMethodFive2 in comments, which includes an implementation. With the
original  empty atomicMethodFive the Genome was crashing.

* kMeans .kMeans => replace the FileImputStream with getResourceAsStream that
allows to read the configuration file from any location in the classpath. In
this case, we are reading the KMeans input file from the deuceTests.jar.

* ssca2.GetUserParameters => change the type of two arguments from double to integer.

* vacation.Client => move the parameterization arrays into their own atomic
operation. This change turns these arrays private to their transactions.
Fixes to StmBench7:

* DeuceSTMOperationExecutor => split the atomic block in two separated blocks,
one for the execution of read-only operations and other for read-write. Some
STMs, such as the LSA, keep track of the functions  that perform write
operations and for those ones it will not try to execute read-only transactions.
So to take advantage of the lightweight behavior of read-only transactions we
need to keep a separated method reserved for the execution of read-only
operations, otherwise the STM will not perform read-only transactions.

* BenchThread => this class keeps two multi-dimensional arrays to register the
operations TTC and highest TTC log. Yet, these arrays are thread-local and do not
need to be transactified by Deuce, with STM barriers to access them. So, we moved
them into an auxiliary class ThreadStats and exclude this class from Deuce
instrumentation.

* BenchThread => the system property uniqueop can specify a single operation to
be executed by this benchmark.
New build.benchmarks.xml to execute Deuce benchmarks

* build.benchmarks.xml => includes the main configurations for the execution
of all benchmarks included in the Deuce distribution. For each benchmark
provides both configurations with, and without, the runtime capture analysis
activated.

* AvailableMem and AvailableProcs => utility classes used by the
build.benchmarks.xml.
Merge remote branch 'fmc/fix/benchmarks' into develop
JVSTM-lock-free (jvstm-2.0) integration in Deuce

* new package org.deuce.transform.jvstm including 3 additional
transformations to support the JVSTM: EnhanceTransactional,
EnhanceVBoxArrays and EnhanceStaticFields.

* new package org.deuce.transform.jvstm containing the new
Context and ContextDelegator implementations specific for the
JVSTM.

* Agent => now the Agent supports pre Enhancers, such as the
post Enhancers, but performing before the standard Deuce
instrumentation.

* Agent => new utility function loadClass to load the
auxiliary classes generated by the pre Enhancers e.g. EnhanceStaticFields.

* ExcludeIncludeStore => additional semantics for immutable classes,
distinct from the already existent Exclude. Immutable classes correspond
to instrumented classes containing a  transactional version of its methods
but without performing STM barriers. So, it allows that instances of these
classes may be invoked through transactional interfaces and avoid an
AbstractMethodError.

* The new semantics to immutable classes require minor changes to
DuplicateMethod and MethodTransformer classes.
JVSTM-lock-free (jvstm-2.0) integration in Deuce

Fixes to existent unit tests and include new unit tests specific for JVSTM.

* Minor change to existent unit tests, regarding the behavior of the
JVSTM, which does not store data in-place. So, if the assertion is made
getting transactional data without STM barriers, then it can get
inconsistent values. So it includes Atomic in the getters of the
transactional classes.

* New unit tests for the JVSTM: org.deuce.utest.jvstm,
org.deuce.utest.point.jvstm.units.gc and org.deuce.utest.point.jvstm.units.
JVSTM-lock-free (jvstm-2.0) integration in Deuce

* build.benchmarks.xml => include scripts for the configuration and
execution of the benchmarks with the JVSTM lock free and performing
capture analysis.

* To support Deuce transactional arrays with JVSTM we use the VBox
Array approach, meaning that arrays are wrapped inside a VBox.
However, when we access arrays from a non-transactional scope,
we are not using STM barriers and we cannot deal directly with VBoxes.
So, in this case we unwrap the encapsulated array from the VBox.
Yet, this solution has a limitation regarding multi-dimensional arrays,
due to the big overhead of unwrapping the encapsulated array from
the VBox.
So every time an unwrap operation occurs for a multidimensional array,
then it raises an exception alerting the end-user programmer. In this case,
one of the recommended workarounds is to access those arrays through
atomic indexers (which are performed within a transaction) and avoid
the unwrap. For this purpose we make some minor changes to some
benchmarks replacing the arrays access by atomic indexers.
Merge pull request #1 from fmcarvalho/feature/jvstm-lock-free

feature/jvstm-lock-free
[maven-release-plugin] prepare release deucestm-licm-1.3.0
Merge commit 'deucestm-licm-1.3.0'