Details
-
Type:
New Feature
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 3.0.1
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
The core part of the TuningFork Visualization Platform is now available as an open source project on sourceforge (https://sourceforge.net/projects/tuningforkvp). We've found the detailed vertical performance profiling it enables fairly valuable for several projects we've used it on. I believe it is also quite likely to be a valuable addition to the tools we use to develop and understand Jikes RVM and would be useful to our user community.
I propose to put together an initial prototype in a branch in the Jikes RVM repository. For the initial round, there will be three main work items:
(1) Basic TF trace engine in Jikes RVM. This can be based on the lower levels of the existing TuningFork Java trace generation library, but I'll need to build a new high level engine that is specialized for the Jikes RVM context.
(2) Replace the functionality of VM_AOSLogging with TuningFork event generations + visualizations to help observe the behavior of the adaptive system.
(3) A visualization of the assignment of committed pages to the various MMTk spaces that make up the heap (instrumenting org.mmtk.plan.Plan.Space acquire/release operations).
(1) and (2) should be fairly straightforward coding exercises.
(3) will raise some interesting design issues about tracing APIs in MMTk. We don't want a proliferation of trace-engine specific code in MMTk. In the branch, I'm initially going to do something fairly hacky that won't be suitable for merging back to the trunk, but will enable work on the visualization side to begin. Before any of the MMTk instrumentation can be considered for merging back to the trunk, we'll want a clean, efficient, and trace engine neutral way of getting the information out of MMTk and to the various potential consumers (TuningFork, GCSpy, etc).
I'd like to merge over most of the branch for inclusion in the 3.0.1 release. The parts that would come over more or less unchanged are:
(1) modified tuningfork trace generation library from the tuningforkvp project (top-level: tuningforklib). This is EPL-licensed, so for simplicity of license management it needs to be kept in its own sub-directory tree
(2) Changes to MMTk to add an instrumentation interface and to hook Page acquire/release events.
(3) New files in Jikes rvm (src/org/jikesrvm/tuningfork to build Jikes RVM specific higher level function on top of the low-level tuningforklib.
(4) command line options, thread start/exit hooks, etc. to tie tuingfork into Jikes RVM.
In the branch, I'd started to replace the AOSLogging support with TuningFork instrumentation. I'm not that happy with the way this went, so I propose to not merge this portion of the change set over. I'll do it in a slightly different way on the head after the merge is done.
If there are any objections or concerns, please raise them by end of day Sept 29th. I'd like to start merging the code over on the 30th.