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.

Please enable Javascript to view the screen cast

Monitor events versus locking situations

In the screencast below, I discuss cross-links between the various monitor views. The profiled test program is the same as in the screencast on Locking graphs in JProfiler.

Please enable Javascript to view the screen cast

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.

Please enable Javascript to view the screen cast

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();
        }
    }
}

Allocation recording explained

In the screencast below, I explain allocation recording in the dynamic memory views in JProfiler.

Please enable Javascript to view the screen cast

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.

Please enable Javascript to view the screen cast

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.