Introduction

This is the instrumentation tool developed with Phoenix SDK Pre-release July 2007 for porting PAMM to windows platform. This tool can work well with the managed binary code written in either C# or managed C++. The instrumented code is supposed to check whether to invoke a garbage collection after a certain amount of new objects are created during the runtime, depending on the current memory usage information acquired from .net virtual machine.

Basic Manual

Acquiring the Code
The code can be checked out through svn with either of the two commands:
  • svn co file:///p/compiler/repos/PAMM_Phx_Jul07/trunk PAMM_Phx_Jul07
  • svn co svn+ssh://login@<cs-machine-name>/p/compiler/repos/PAMM_Phx_Jul07/trunk PAMM_Phx_Jul07

Project Directory
The project contains two sub-directory:
  • PAMM_Phx is the directory containing the source code of the main instrumentation tool including reading and writing managed binary and code injection.
  • PAMM_Handle is a DLL library which will be called by the instrumented binary to check the memory usage and call a garbage collection if necessary.
The already built executables are included in the subdirectory named bin.
Instrumenting a Managed Binary
To use PAMM_Phx to instrument a managed binary application, the Phoenix SDK should be installed on the computer. The package can be downloaded for free from Microsoft. Make sure you have the PAMM_Phx.exe, PAMM_Handle.dll ,and the application to be instrumented in the same directory to make the tool work properly. To instrument a managed binary application, simply type in the following instruction in the Phoenix SDK command prompt environment:
  • PAMM_Phx /in <filename> /num [num_obj] /mem [mem_bound]
    • /in is the filename of the binary application to be instrumented
      • Currently can instrument C# binary or strictly managed C++ binary.
    • /num [num_obj] should be an integer number greater than 0. This is to specify the number of new objects before a memory check. In other words, during the runtime, a memory check is performed every num_obj new objects are created. If not provided, the default number will be set to 5000.
    • /mem [mem_bound] should be an integer number not less than 0. This is to specify the memory upper bound for the application during the runtime and the current unit is megabyte. When a memory check is performed, if the memory used by the application exceeds mem_bound MB, a garbage collection on the heap will be forced. The default value for this parameter is 0, which means there is no manually set upper bound and the .net virtual machine is in charge of the memory management.
After the instrumentation is done, a new binary code will be generated in the name of the application with a "-pamm" suffix attached.
Rebuilding the project
The project is created in Visual Studio 2005 ,and written in C#, a solution file may be found under the two subdirectories respectively. One can simply load the solution file into Visual Studio 2005, or Visual C# Express 2005, make whatever modification, and then rebuild it without any difficulty. Keep in mind that, to successfully rebuild PAMM_Phx, the Phoenix SDK is required and the current release of Phoenix SDK does not support Visual Studio 2008 or Visual C# Express 2008.

Benchmarks

All benchmarks can be acquired by:
  • svn co file:///p/compiler/repos/CSharp_Benchmarks/trunk CSharp_Benchmarks
  • svn co svn+ssh://login@<cs-machine-name>/p/compiler/repos/CSharp_Benchmarks/trunk CSharp_Benchmarks

  • lcscbench - compiler benchmark
    • Description: lcscbench is based on the front end of a compiler for C# written in C# and uses a generalized LR (GLR) parsing algorithm. lcscbench is compute and memory intensive, requiring hundreds of megabytes of heap for the largest input file provided (a C# source file with 125,000 lines of code). The source contains approximately 17,000 lines of code if machine-generated code is not counted.
    • Developers: Dave Hanson and Todd Proebsting (Microsoft Research)
    • Compatibility: CLR 1.0.3705, Rotor 1.0 (others untested)
    • Location:
      CSharp_Benchmarks/lcscbench/

  • ahcbench - compression benchmark
    • Description: ahcbench is based on compressing and uncompressing an input file using Adaptive Huffman Compression. It is written in C#. ahcbench is compute-intensive, requiring a relatively small heap. There are 1267 lines of code in the source for the benchmark.
    • Developer : Based on an implementation of Adaptive Huffman Compression by Stephen Toub
    • Compatibility: CLR 1.0.3705, Rotor 1.0 (others untested)
    • Location:
      CSharp_Benchmarks/ahcbench/

  • SharpSATbench - satisfiability solver benchmark
    • Description: SharpSATbench is a CLI managed-code benchmark based on a clause-based satisfiability solver where the logic formula is written in Conjunctive Normal Form (CNF). SharpSATbench is compute-intensive, requiring a moderate-sized heap. There are 10,900 lines of code in the C# source of the benchmark.
    • Developer: Lintao Zhang
    • Compatibility: CLR 1.03705, Rotor 1.0 (others untested)
    • Test Inputs: many additional .cnf test inputs are available from http://www.ece.cmu.edu/~mvelev/sat_benchmarks.html
    • Location:
      CSharp_Benchmarks/SharpSATbench/

  • Java Grande
    • Description: A simplified port of a subset of the Java Grande benchmark. Timings are removed, so lowering the initial constants is recommended.
    • Contents:
    • Location:
      CSharp_Benchmarks/JGrande/

  • mono
    • Description: Five of the larger mono test suite programs
    • Contents: * casts.cs - Casting test * test-49.cs - Switch operator test - Phase Profile [10 instrs/interval] * test-233.cs - Comparison test - Phase Profile [10 instrs/interval] * test-254.cs - Reflection test * test-269.cs - References test
    • Location:
      CSharp_Benchmarks/mono/

  • SciMark
    • Description: Modification of SciMark C# Benchmark port for compatibility with Visual Studio 2005 Beta 1. To run each individual part, comment out the unwanted parts in CommandLine.cs
    • Contents: * FFT.cs - Fast fourier transformations - Phase Profile [10k instrs/interval] * LU.cs - LU factorization - Phase Profile [100k instrs/interval] * MonteCarlo.cs - Monte Carlo algorithm * SOR.cs - Successive Overrelaxation algorithm * SparseCompRow.cs - Sparse Matrix Multiplcation * complete program run - Phase Profile [100k instrs/interval]
    • Location:
      CSharp_Benchmarks/SciMark/

  • GC Benchmarks for C#
    • Description: Benchmarks written or collected by Daniel Spoonhower from CMU. These benchmarks have interesting behavior from the point of view of the garbage collector. They all allocate large amounts of data and create interesting heap structures.
    • Contents:
      • Splunc - This program builds a splay tree of random integer values, truncating the resulting tree at a fixed depth after each insertion. The lifetimes of objects inserted into the tree follow a log-normal distribution. The splay tree implementation was ported from a version written by Danny Sleator.
      • Raytracer - The benchmark was originally part of the Java Grande Forum Benchmark Suite. The original version is a multi-threaded 3D renderer. My port runs as a single-threaded application only.
      • GCBench - This is a port of a benchmark written by John Ellis and Pete Kovac and later modified by Hans Boehm. It builds large tree structures both from the top down and the bottom up.
      • GCOld - The original version was developed by Dave Detlefs and later modified and rewritten by Matthias Jacob and Will Clinger. This is another tree-based, artificial benchmark.
    • Location:
      CSharp_Benchmarks/gc_benchmarks/


This topic: Main > TWikiGroups > CompilerGroup > CompilerRepository > PAMM_Phx_Jul07
Topic revision: r5 - 2008-06-11 - JiashengShi
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding URCS? Send feedback