Cumulating and filtering monitor events

In the screencast below, I explain how monitor events in the locking history graph can be cumulated and how you can select monitors and threads of interest.

Locking graphs in JProfiler

In the screencast below, I present some of the features in the locking graphs that have been introduced in JProfiler 6.

The test class that is profiled in this screen cast is given below:



public class MonitorTest {

// The only monitor that all threads are blocking or waiting on
private static final MonitorTest monitor = new MonitorTest();

public static void main(String[] args) throws InterruptedException {

// All threads execute this runnable, each thread acquires the
// monitor, works for 3 seconds and then waits on the monitor
Runnable runnable = new Runnable() {
public void run() {
synchronized (monitor) {
try {
// Instead of doing any real work, the thread just
// sleeps for 3 second
Thread.sleep(3000);
monitor.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}

}
};

// 3 threads are started with an offset of 500 ms
new Thread(runnable, "Test Thread 1").start();
Thread.sleep(500);
new Thread(runnable, "Test Thread 2").start();
Thread.sleep(500);
new Thread(runnable, "Test Thread 3").start();

// After 20 seconds, all threads are woken up and the test class
// terminates
Thread.sleep(20000);
synchronized (monitor) {
monitor.notifyAll();
}
}
}

Fine-tuning console installers

In the upcoming install4j 4.2.4 release, we’ll expand on the improvements that were introduced with the visibility script in install4j 4.2.3.

The GUI installer operates in a “one screen at a time” mode while the console installer does “one question at a time”. Due to this difference, the automatic translation of form screens from GUI to console mode will not always be optimal.

In 4.2.4 we will introduce a “Console handler” form component that allows you to fine-tune the console mode of your installers. The form component is invisible and has no effect in GUI mode. Its action is defined in the “Console script” property:

Besides the usual parameters for form components, the script is passed a “console” parameter, which is of type com.install4j.api.screens.Console and offers a number of methods for interacting with the user on the console. This has previously only been offered in the API for the development of custom screens and custom form components.

In the console script shown above, an error condition is handled in the middle of the form component sequence. In GUI mode, such error conditions are usually handled in the validation script of the screen, but due to the lack of “screens” in console mode, the validation might be more appropriate at an earlier time.

Another scenario for the use of console handler form components are form screens that do no require user input. In such a case, you could add a console handler form component and set its console script to


console.print("Please read the information above");
console.waitForEnter();
return true;

Thread states in the CPU profiling views

In the screencast below, I explain the thread status selector and the different threads states in the CPU profiling views.

Appending to redirection files

install4j has always offered the possibility to redirect stderr and stdout to files. The main purpose of this feature is to analyze uncaught exceptions and to get debug information when something goes wrong in a customer’s installation.

The redirection files are created lazily, meaning that as long as there is no output, the file will not be created or replaced. However, once output is detected, the redirection file is created or overwritten. This has been the only option so far and while it is often sufficient to retain the error or debug output of the last run, in some cases you might want to keep the entire output over multiple invocations of the launcher.

In the upcoming install4j 4.2.4, we have added this feature and in the redirection step of the launcher wizard, you can change the classic “Overwrite” behavior to “Append”.


The redirection file will still be created lazily, but it will be appended to if it already exists.

Overview of profiling views and profiling settings

We now have a list of screencasts for JProfiler on our web site that is generated from this blog. In order to include the older demos (without audio) into that list, I post them below:

  • Overview of profiling views in JProfiler See a brief overview of the most important profiling views in JProfiler. Some important functionality is shown to give you an idea on how JProfiler works.
  • Getting started and session settings See how easy it is to get started with profiling. Important aspects of the session configuration like profiling settings, triggers and method call recording filters are shown.

Both demos take about 7 minutes and open in a new window. The were recorded for JProfiler 5.0 but are still quite accurate for JProfiler 5.2.

install4j and Java for Mac OS X v10.5 Update 4

Unfortunately the latest release of Java 6 on Mac OS X a few days ago broke all installers on Mac OS X that require Java 6 as a minimum Java version.

This is why we have sped up our release schedule for 4.2.3 and we pushed out the release today.

The error message you get with installers that are generated by older versions of install4j is:

 
Java application launched from PPC or bad stub. Relaunching in 32-bit, and tagging sub-processes to prefer 32-bit with $JAVA_ARCH=i386.
[JavaAppLauncher Error] This process is [i386] and was re-exec'd from [i386], but for some reason we are trying re-exec to [].

How could this happen? The explanation goes like this: Installers on Mac OS X ship their own binary Java application stub. Prior to Java 6 this application stub only contained 32-bit executables for PPC and Intel architectures. So far, Java 6 is only available on 64-bit Intel machines. From the beginning, the 32-bit stub continued to work with Java 6. This behavior was changed in Java for Mac OS X v10.5 Update 4, so we had to add a 64-bit executable to the Java application stub.

If you’re on an older version of install4j and cannot update to the latest version for whatever reason, you can copy the file $INSTALL4J_HOME/resource/macos/JavaApplicationStub from a 4.2.3 installation to your older installation.