11/27/2011

My tcsh notes

Settings to remember when I need to use tcsh in a foreign environment:

set prompt="%/ > "
# set prompt="%{\033]0;%M: %c\007%}%/ > "
set complete=enhance
set autolist=true

set colorcat
setenv GREP_OPTIONS --color=auto
setenv GREP_COLOR 32
Copy the above lines to $HOME/.tcshrc. The first 3 are the most important ones to remember. Setting prompt to "%/ > " puts the $cwd in the front of the command prompt. $cwd is the same as the all-upper-case $PWD but is easier to type.

To list current key bindings in tcsh:
$ bindkey
"^A" -> beginning-of-line
"^D" -> delete-char-or-list-or-eof
"^E" -> end-of-line
"^I" -> complete-word
"^J" -> newline
"^K" -> kill-line
"^L" -> clear-screen
"^M" -> newline
"^P" -> up-history
"^T" -> transpose-chars
"^U" -> kill-whole-line
"^W" -> kill-region
... ...
To use vi-mode or emacs-mode command-line editing and navigation:
bindkey -v
bindkey -e

11/14/2011

Why use ThreadFactory

When submitting tasks to java executor service, some thread will be allocated to perform that task. The servicing thread may be assigned from the internal thread pool, or created on-demand. Each executor service has an associated ThreadFactory, and a default ThreadFactory if the application does not specify one. For non-trivial apps, it's always a good idea to set a custom ThreadFactory.

1, To set a more descriptive thread name. With the default ThreadFactory, it gives thread names in the form of pool-m-thread-n, such as pool-1-thread-1, pool-2-thread-1, pool-3-thread-1, etc. When these threads showing up in debugger, profiler, or monitoring tool, it's hard to know their purpose and how they were started.

When analyzing a thread dump, thread name is the only clue to trace to the source where the thread pool or executor service is created.  The stack trace contains all JDK classes with java.lang.Thread.run at the very bottom.  It doesn't tell anything about your application.

2, To set thread daemon status. The default ThreadFactory produces non-daemon threads.

3, To set thread contextClassLoader to appropriate value. Threads created by the default ThreadFactory will inherit the contextClassLoader from the parent thread, which may not be what you want. In general, a pooled thread itself should not be associated with any specific class loader. Instead, the submitted task has the best knowledge about its class loading requirement, so the task Runnable or Callable should manage the thread contextClassLoader for the duration of its run method.

If the new thread does not need to access classes loaded in the parent thead, set its contextClassLoader to null. If a task needs visibility to a class loader, set its contextClassLoader at the beginning of its run method, and restore its contextClassLoader right before exiting run method.

The default ThreadFactory in JDK 6 java.util.concurrent is a package-private static nested class in java.util.concurrent.Executors:

static class DefaultThreadFactory implements ThreadFactory {
        static final AtomicInteger poolNumber = new AtomicInteger(1);
        final ThreadGroup group;
        final AtomicInteger threadNumber = new AtomicInteger(1);
        final String namePrefix;

        DefaultThreadFactory() {
            SecurityManager s = System.getSecurityManager();
            group = (s != null)? s.getThreadGroup() :
                                 Thread.currentThread().getThreadGroup();
            namePrefix = "pool-" +
                          poolNumber.getAndIncrement() +
                         "-thread-";
        }

        public Thread newThread(Runnable r) {
            Thread t = new Thread(group, r,
                                  namePrefix + threadNumber.getAndIncrement(),
                                  0);
            if (t.isDaemon())
                t.setDaemon(false);
            if (t.getPriority() != Thread.NORM_PRIORITY)
                t.setPriority(Thread.NORM_PRIORITY);
            return t;
        }
    }
Note that poolNumber is declared as static final and threadNumber as final. Each instance of ThreadFactory is tied to a unique pool, and a static poolNumber tracks the sequence of all instances of DefaultThreadFactory. An instance of ThreadFactory (and the associated pool) contains multiple threads, and the instance field threadNumber tallies all threads therein.

Both poolNumber and threadNumber fields are of type java.util.concurrent.AtomicInteger to take advantage of its atomic compound operations. Their initial value is 1 and getAndIncrement() is invoked to produce sequence like 1, 2, 3. Alternatively we could set its initial value to 0 and invoke incrementAndGet() to produce the same sequence.

Why poolNumber and threadNumber need to guard against concurrent access and modification? poolNumber is static and thus a shared data among all instances of DefaultThreadFactory. Multiple instances of DefaultThreadFactory may be incrementing it simutaneously, so it needs to be thread-safe.

As for threadNumber, the creation of threads, either initially at execution service startup time, or under heavy load, may be serialized by the execution service. But an instance of ThreadFactory can be passed around and associated with multiple execution service. Therefore, the internal state of ThreadFactory needs to be thread-safe and immutable.

11/09/2011

Notes on Java Debugger (NetBeans)

Some notes on using NetBeans Java Debugger. They also apply in principal to other Java debuggers.

1, Set line breakpoint (the most common breakpoint), optionally make them conditional breakpoint to filter out irelevant hits. Sometimes I found conditional breakpoint doesn't seem to work and the execution always pauses regardless of the condition.

2, Use field breakpoint to intercept field access and/or modification. This is very useful to track all access and mutation of the field without having to inspect its setter and getter. And some fields don't even have setter or getter methods.

3, Use method breakpoint to inspect method entry and exit. This is just a variation of line breakpoint.

4, Use class breakpoint to track class loading and unloading. This is useful when you just have a vague idea that a certain class will be executed but don't know which part. When the class breakpoint is hit, you can then note down the calling stack trace.

5, Exception breakpoint is also available but haven't tried that.

6, Rewind (step back) the calling sequence by popping off the top element in the calling stack. You can do it from Debugger menu, or the context menu of a particular thread.

7, Add debug buttons to tools bar, including "Attach Debugger ..." button. If "Attach Debugger button is not included by default, you can customize the tool bar by dragging it into the bar. This is very convenient for attaching debugger to remote java process.

8, Apply code changes dynamically to the debugging session, without restarting the remote java application. Debug > Apply Code Changes, or Apply Code Changes button in tool bar. Note that the code changes are not effective in current debugging session. To make it permanent, need to rebuild and restart the remote application.

9, You can start multiple debugging sessions by attaching to different java processes. For example, to debug both the client side and server side operations. Pay attention to where the execution is, the client side, or the server side? Sometimes you can't tell where you are by just looking at the current class name, because some classes are loaded by both the client side and the server side programs.

10, To copy the current stack trace, go to Debug > Evaluate Express, enter
Thread.dumpStack();
The stack trace will appear in the application's log file or console.

11, If you need to step into source code outside your main project, get hold of its source code if available, and create a IDE project off it. That may involve checking it out from different repo, with different scm tool, or download source zip/jar files from maven repo. A decompiler may be able to handle some simple classes, but tend to produce incomplete source code for large, complext classes.

12, Always attach JDK source code and javadoc to your IDE. NetBeans Tools > Java Platform > JDK 1.6 > Sources. You will need to download the JDK source installer and install it to disk. Source files for JDK classes are located in j2se/src/share/classes.

Finally, shortcuts:

Step Over        F8
Step Into F7
Continue F5
Breakpoints Ctrl-Shift-5
Variables Ctrl-Shift-1
Watches Ctrl-Shift-2
Terminate Debug Shift-F5