Instrumentation-based profiling provides a number of benefits, but can also cause high performance overhead. The negative impact of this overhead could be mitigated considerably if only a small part of the target application (e.g. one that has previously been identified as a bottleneck) is instrumented, possibly for a short time only, while the rest of the application code runs at full speed. In this paper we present an experimental profiling system called JFluid, which includes a modified Java/spl trade/ VM and a GUI tool, and addresses both of the above issues. Our tool supports dynamic instrumentation of a group of methods defined as an arbitrary "root" method plus all methods that it calls (a call subgraph). Methods that belong to a call subgraph are revealed and instrumented lazily, to minimise the number of methods instrumented unnecessarily. Measurements that we obtain when performing full and partial program profiling show that the overhead can be reduced substantially using this technique, and that it is more beneficial when used for large server-side Java applications as opposed to small benchmarks.

Keeping the code of a Java application consistent (code is consistent if all of the project classes can be recompiled together without errors) prevents late linking errors, and thus may significantly improve development turnaround time. In this paper we describe a make technology for the Java programming language, that is based on smart dependency checking, guarantees consistency of the project code, and at the same time reduces the number of source code recompilations to the minimum. After project code consistency is initially assured by complete recompilation, the information extracted from the binary classes is stored in a so-called project database. Whenever the source code for some class C is changed, its recompiled binary is compared to the old version of C preserved in the project database. As a result, we find a minimum subset of classes that depend on C and may be affected by the particular change made to it. These are recompiled in turn, and absence of compilation errors at this phase guarantees the consistency of the new project code. To determine which dependent classes to recompile, we categorize all source incompatible changes, and for each category establish a criterion for finding the smallest possible subset of dependent classes.