Moazam Rajas Sun hosted weblog garbage collection II

The javac command on OS X does not support the -Xmx or -Xms switches for changing default memory sizes. For example, the following works on Solaris & Windows, but fails on OS X Tiger,

javac -J-Xms256m -J-Xmx256m Hello.java
javac: invalid flag: -J-Xmx256m Usage: javac

Other switches, such as -J-Xloggc:file.out work fine on OS X.

I've tried passing the switch as '-Xms256m' also, but that also fails. This is a pretty significant bug because without being able to pass -Xms/Xmx values to javac, certain large software builds will fail with an OutOfMemory error.

This is on OS X 10.4.2, with Java 5.

ae86:~ moazam$ java -version
java version "1.5.0_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-56)
Java HotSpot(TM) Client VM (build 1.5.0_02-36, mixed mode, sharing)

I've filed a bug with Apple, let's see what happens.

Somewhat belated on my part, but nevertheless..

Calvin Austin wrote up a quick little piece showing that he can dtrace a Linux program running on Solaris 10 (x86) and peek into the stack of a Java process.

Read here

As per Azeem, the C2VMGuy, JDK 6.0 weekly snapshots are available to the public here.

The Java 5.0 source code has been made available under the Java Research License.

Calvin beat me to the punch..plus he has more info in his entry.

I've been bogged down by work so much that I have not had a chance to update this page in eons. Anyways...I've been playing with my new Apple Dual G5 machine lately when I get time in the wee hours of morning. Hopefully in a week or so when things settle down I can actually start delving into the nitty gritty of this system.

Meanwhile, back at the ranch..

Apple has their own Java implementation and with it goes their own set of JVM options and defaults. Many options are the same as the standard Sun options but there are definitely some OS X specific ones also.

Check out the options at the Apple Developer site, here.

Joe Mocker, a Sun employee, took up the momumental task of documenting and versioning the vast majority of JVM options available in 1.3.1-1.5.0 JVMs. I found this on the blogs.sun.com by way of Mike Watt

Now, here goes the nanny speech, please realize, there are supported flags, and unsupported flags. Just because you see a nice nifty flag -XX:[flag] does not mean you should run off and experiment with it on your production machines! I can't count how many times I've seen people 'tune' their VM by adding options only to have their application performance suffer.

Like the Java HotSpot VM Options page says,

# Options that begin with -X are non-standard (not guaranteed to be supported on all VM implementations), and are subject to change without notice in subsequent releases of the Java 2 SDK.
# Because the -XX options have specific system requirements for correct operation and may require privileged access to system configuration parameters, they are not recommended for casual use. These options are also subject to change without notice.

So, without further ado, here is the link to the canononical list of JVM options.

I have not had much time to write on my weblog or even read other peoples weblogs lately. Of course, this means that I missed Calvin Austins post about the jps and jinfo commands.

From Calvins post, here is the output from running jinfo on a Java process.

# jinfo 1361
Attaching to process ID 1361, please wait...
Debugger attached successfully.
Client compiler detected.
JVM version is 1.5.0-beta3-b60
Java System Properties:

java.runtime.name = Java(TM) 2 Runtime Environment, Standard Edition
sun.boot.library.path = /usr/java/jdk1.5.0/jre/lib/i386
java.vm.version = 1.5.0-beta3-b60
java.vm.vendor = Sun Microsystems Inc.
java.vendor.url = http://java.sun.com/
path.separator = :
java.vm.name = Java HotSpot(TM) Client VM
file.encoding.pkg = sun.io
user.country = US
sun.os.patch.level = unknown
java.vm.specification.name = Java Virtual Machine Specification
user.dir = /usr/java/jdk1.5.0/demo/jfc/Stylepad
java.runtime.version = 1.5.0-beta3-b60
java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment
java.endorsed.dirs = /usr/java/jdk1.5.0/jre/lib/endorsed
os.arch = i386
java.io.tmpdir = /tmp
line.separator = 

java.vm.specification.vendor = Sun Microsystems Inc.
os.name = Linux
sun.jnu.encoding = ISO-8859-1
java.library.path = /usr/java/jdk1.5.0/jre/lib/i386/client:
/usr/java/jdk1.5.0/jre/lib/i386:
/usr/java/jdk1.5.0/jre/../lib/i386
java.specification.name = Java Platform API Specification
java.class.version = 49.0
sun.management.compiler = HotSpot Client Compiler
os.version = 2.4.9-e.3smp
user.home = /root
user.timezone = 
java.awt.printerjob = sun.print.PSPrinterJob
file.encoding = ISO-8859-1
java.specification.version = 1.5
java.class.path = Stylepad.jar
user.name = root
java.vm.specification.version = 1.0
java.home = /usr/java/jdk1.5.0/jre
sun.arch.data.model = 32
user.language = en
java.specification.vendor = Sun Microsystems Inc.
java.vm.info = mixed mode
java.version = 1.5.0-beta3
java.ext.dirs = /usr/java/jdk1.5.0/jre/lib/ext
sun.boot.class.path = /usr/java/jdk1.5.0/jre/lib/rt.jar:
/usr/java/jdk1.5.0/jre/lib/i18n.jar:
/usr/java/jdk1.5.0/jre/lib/sunrsasign.jar:
/usr/java/jdk1.5.0/jre/lib/jsse.jar:
/usr/java/jdk1.5.0/jre/lib/jce.jar:
/usr/java/jdk1.5.0/jre/lib/charsets.jar:
/usr/java/jdk1.5.0/jre/classes
java.vendor = Sun Microsystems Inc.
file.separator = /
java.vendor.url.bug = http://java.sun.com/cgi-bin/bugreport.cgi
sun.io.unicode.encoding = UnicodeLittle
sun.cpu.endian = little
sun.cpu.isalist = 

VM Flags:

Dtrace, Zones, jps, jstack, jstat, jconsole, jmap....these are some of the upcoming technologies and tools which will definitely make my life alot easier. You can check out the docs concerning these Java tools here.

I got an email from Fredrik Paulsson asking about my previous entry concerning "Why can't I allocate 2GB of heap to the JVM on Windows?" Fredrik (and others) have asked about the new /3GB and /PAE switches available in certain releases of Windows (2000/2003, AS/ES).

There is a description of the /3GB switch over at the Microsoft website.

Anyways, the use of this switch does not enable the JVM to allocate more than 2GB heap on Windows. Why? (The Sun VM engineers can step up and correct me here if I'm wrong) The Java Virtual Machine wants a contiguous allocation of memory. The /3GB switch in Windows does not allow that. The use of non-contiguous memory space for the 32bit JVM would most probably cause performance issues. Can you imagine doing garbage collection over 3GB of non-contiguous RAM? *shudder*

So what is the solution? Honestly, if you're going to use big RAM, just upgrade to 64bit CPUs and a 64bit OS. Windows, Linux, and Solaris all come in 64bit versions now.

PS> According to one of the Java GC gods here at Sun, "The Java object heap has to be allocated in contiguous virtual addresses, for implementation reasons." (P.Kessler)

I had not seen this document on analyzing stack traces until Calvin Austin mentioned it on another weblog. Good base reference information here.

Thread dumps, stack traces, pstacks, and pmaps, these are some of my favo...oh er, nevermind.

A while back I was supposed to write up a detailed guide to reading stack traces for training new engineers, but alas my laziness restricted me to a thin article about debugging thread related hangs instead.

Luckily for me (and the trainees), Rajiv Shivane wrote up a very detailed document on reading stack traces. I've mentioned this link before here, but unfortunately not in the proper context.

Thread dumps and stack traces are probably some of the least understood features of java. Why else would I come across developers who have no clue what do do after looking at an Exception stack trace?

[read more]

Stephen Fitch mentioned that the J2SE Internals & Troubleshooting class has become available to the public for $100! This class used to be a Sun Internal only class before and had "Internal Only" stamps all over it. Anyone even mildly interested in Java Internals should take this class, it's simply excellent and provides a very good base of understanding. Internally we've delivered this class to US, Singapore, and Aussie engineers.

J2SE Internals and Troubleshooting

PS> Who exactly is Stephen Fitch? He's the Escalation Manager for J2SE here at Sun. This basically means that we run to him when all hell breaks loose.

According to Eric Schrock, it looks like the upcoming release of Solaris Express will have enhancements which will allow pstack to display java frames. [read all about it]

As Calvin Austin mentioned, J2SE 1.5.0 is now known as J2SE 5.0. J2EE will be J2EE 5.0. I'm in the middle about this, but still not 100% sure what I think of the namechange.

JavaOne is pretty packed, it was very interesting watching the horde descend upon the pavilion floor when the clock struck 11. I went over to WWDC, my first visit ever, the pavilion is pretty small compared to JavaOne.

I need to figure out how to steal one of the huge BEA beanbags without anyone noticing.

ObJVMInternalsEntry> The Sun folks (Misha Dmitriev) were showing off JFluid and the built in Java Performance Console tool which will be bundled with J2SE 5.0.

I just got off a 6am con-call with a customer having some problems with Java 2D/Swing performance on multiple monitor systems. Unfortunately we don't have any sort of test case so we're shooting slightly in the dark for now. A quick search for Java 2D optimization and runtime flags brings up some interesting stuff.

From the 1.4.2 Release Notes:

One example of a known problem is that using Direct3D on some small subset of Windows 2000 systems has been known to cause a system crash. You can also try launching your application with the following command-line flag set:

-Dsun.java2d.d3d=false
This forcibly disables our use of Direct3D and avoids any Direct3D-specific problems.
You can also try the following flag:

-Dsun.java2d.ddoffscreen=false
This flag disables our use of DirectDraw and Direct3D for offscreen images (such as the Swing back buffer).
If problems persists, try launching the application with this flag:

-Dsun.java2d.noddraw=true
This flag disables our use of DirectDraw and Direct3D completely and thus avoids any problems you may be seeing associated with our use of those APIs and their respective drivers on your system.
For more information about performance-related flags, see Flags for Controlling Performance and Quality, a section in the High Performance Graphics white paper (also available in PDF format).

* Drawing many simple primitives to an accelerated offscreen surface may result in a JRE crash and corruption of the underlying graphics subsystem due to leakage of GDI resources. This problem is being tracked as bug 4766813. The workaround is to turn off offscreen acceleration:
-Dsun.java2d.ddoffscreen=false


And from the Graphics Performance Improvements white paper:

# -Dsun.java2d.noddraw=true
Setting this flag to true turns off DirectDraw usage, which sometimes helps to get rid of a lot of rendering problems on Win32.

# -Dsun.java2d.ddoffscreen=false
Setting this flag to false turns off DirectDraw offscreen surfaces acceleration by forcing all createVolatileImage calls to become createImage calls, and disables hidden acceleration performed on surfaces created with createImage.

# -Dsun.java2d.ddscale=true
Setting this flag to true enables hardware-accelerated scaling. Hardware scaling is disabled by default to avoid rendering artifacts in existing applications. These rendering artifacts are caused by possible inconsistencies between the scale method that the software scaling operation uses (nearest neighbor) and the different scale methods that video cards use. Certain events that occur while an application is running might cause a scaled image to be rendered partially with hardware scaling operations and partially with software scaling operations, resulting in an inconsistent appearance. For now, you can enable acceleration by setting the ddscale flag to true.

I should read my e-mail in more detail. :) It looks like I am going to JavaOne, but I'll actually be working at the Sun java.net booth over at the Apple WWDC. You did know that both JavaOne and WWDC are being held in practically the same location and time, right? Here are the times I'll be at the Sun java.net booth over at WWDC:

Monday	1:00	-	5:00
Tuesday	11:00	-	5:00 (!)
Wednesday	11:00	-	3:00

And on a total tangent...I found a picture of my old office at the Sun Menlo Park campus from back when I worked in the Developer Tools organization.