feature/capture-analysis #23
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 4 commits
May 9, 2013 11:38
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.
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add support to LICM ( lightweight identification of captured memory ),
which is a new lightweight runtime technique to identify captured memory
(memory allocated inside its allocating transaction), for which no
STM barriers are needed.
Using this technique to remove useless barriers, we improved the performance
of all baseline STMs for most benchmarks. In STMBench7 the performance
improved significantly: 4 times for the LSA and 2.6 times for the TL2. Moreover,
running the STAMP benchmarks with our approach shows improvements of 7
times in the best case for the Vacation application.
This work was presented as a poster in the PPoPP13, with the title:
"Runtime Elision of Transactional Barriers for Captured Memory",
Fernando Miguel Carvalho and João Cachopo.
You can find here further details about our implementation .