From 2ae253bea6401f26dddf0c3b78b4e40aefbd0b18 Mon Sep 17 00:00:00 2001 From: Grzegorz Kossakowski Date: Mon, 16 Jul 2012 11:22:40 +0200 Subject: Partest: add `instrumented` test category. --- (taken from README) Tests in `instrumented/` directory are executed the same way as in `run/` but they have additional byte-code instrumentation performed for profiling. You should put your tests in `instrumented/` directory if you are interested in method call counts. Examples include tests for specialization (you want to count boxing and unboxing method calls) or high-level tests for optimizer where you are interested if methods are successfuly inlined (so they should not be called at runtime) or closures are eliminated (so no constructors of closures are called). Check `scala.tools.partest.instrumented.Instrumentation` to learn how to use the instrumentation infrastructure. The instrumentation itself is achieved by attaching a Java agent to the forked VM process that injects calls to profiler. Check `scala.tools.partest.javaagent.ProfilingAgent` for details. --- A few notes on low-level details of this change: * Partest now depends on asm library for byte-code instrumentation (`build.xml`) * Build additional jar called `scala-partest-javaagent.jar` that is used with `-javaagent:` option. (`build.xml`) * Set `-javaagent:` option for all tests in `instrumented/` directory. (`RunnerManger.scala`) * Introduce a new category of tests called `instrumented`. * Add one instrumented test to demonstrate usage and test new infrastructure itself. (`InstrumentationTest.scala`) Review by @phaller. --- test/files/instrumented/InstrumentationTest.check | 4 ++++ test/files/instrumented/InstrumentationTest.scala | 14 ++++++++++++++ test/files/instrumented/README | 15 +++++++++++++++ 3 files changed, 33 insertions(+) create mode 100644 test/files/instrumented/InstrumentationTest.check create mode 100644 test/files/instrumented/InstrumentationTest.scala create mode 100644 test/files/instrumented/README (limited to 'test') diff --git a/test/files/instrumented/InstrumentationTest.check b/test/files/instrumented/InstrumentationTest.check new file mode 100644 index 0000000000..3652df270a --- /dev/null +++ b/test/files/instrumented/InstrumentationTest.check @@ -0,0 +1,4 @@ +true +Method call statistics: + 1 scala/Predef$.println(Ljava/lang/Object;)V + 1 scala/runtime/BoxesRunTime.boxToBoolean(Z)Ljava/lang/Boolean; diff --git a/test/files/instrumented/InstrumentationTest.scala b/test/files/instrumented/InstrumentationTest.scala new file mode 100644 index 0000000000..ec5314c624 --- /dev/null +++ b/test/files/instrumented/InstrumentationTest.scala @@ -0,0 +1,14 @@ +import scala.tools.partest.instrumented.Instrumentation._ + +/** Tests if instrumentation itself works correctly */ +object Test { + def main(args: Array[String]) { + // force predef initialization before profiling + Predef + startProfiling() + // should box the boolean + println(true) + stopProfiling() + printStatistics() + } +} diff --git a/test/files/instrumented/README b/test/files/instrumented/README new file mode 100644 index 0000000000..32d0ef2da5 --- /dev/null +++ b/test/files/instrumented/README @@ -0,0 +1,15 @@ +Tests in `instrumented` directory are executed the same way as in `run` but +they have additional byte-code instrumentation performed for profiling. You +should put your tests in `instrumented` directory if you are interested in +method call counts. Examples include tests for specialization (you want to +count boxing and unboxing method calls) or high-level tests for optimizer +where you are interested if methods are successfuly inlined (so they should +not be called at runtime) or closures are eliminated (so no constructors +of closures are called). + +Check `scala.tools.partest.instrumented.Instrumentation` to learn how to +use the instrumentation infrastructure. + +The instrumentation itself is achieved by attaching a Java agent to the forked +VM process that injects calls to profiler. Check +`scala.tools.partest.instrumented.Instrumentation`. -- cgit v1.2.3