1. Eclipse For Mac

If you find yourself trying to analyze a big heap dump (20-30GB) downloaded from your production server to your staging/test machines. Only to find out that X-over-SSH is too slow then this article is for you. As of Nov 2013, we have 2 options - Eclipse MAT and a hidden gem called Bheapsampler. Option 1: Eclipse Memory Analyzer is obviously the best tool for this job.

However, trying to get the UI to run remotely is very painful. Launching Eclipse and updating the UI is an extra load on the JVM that is already busy analyzing a 30G heap dump. Fortunately, there is a script that comes with MAT to parse the the heap dump and generate HTML reports without ever having to launch Eclipse! It's just that the command line option is not well advertised. Command line heap analysis using Eclipse MAT: Assuming Eclipse MAT is installed and we are inside the mat/ directory, modify MemoryAnalyzer.ini heap settings to use a large heap to handle large dumps: -startup plugins/org.eclipse.equinox.

Launcher1.2.0.v20110502.jar -launcher.library plugins/org.eclipse.equinox.launcher.gtk.linux.x86641.1. 100.v20110505 -vmargs -Xms24g -Xmx24g Run MAT against the heap dump:./ParseHeapDump.sh./todayheapdump/jvm.hprof This takes a while to execute and generates indices and other files to make repeated analysis faster. Then use the indices created in the previous step and run a 'Leak suspects' report on the heap dump./ParseHeapDump.sh./todayheapdump/jvm.hprof org.eclipse.mat.api:suspects The output is a small and easy to download jvmLeakSuspects.zip. This has HTML files just like the MAT Eclipse UI. It can be easily SCP'ed/emailed around. Other report types possible. Org.eclipse.mat.api:suspects org.eclipse.mat.api:overview org.eclipse.mat.api:top components More details -.

Option 2: is something I chanced upon. It is a sampling heap dump reader and so it works for very large heap dumps where MAT sometimes fails. Being a sampling reader, the output is also a little imprecise but helps a great deal when you have nothing else.

The tool seems to be closed source and is very sensitive to heap dump corruptions. As an aside, here's something that might be useful for the initial heap dump quickly. The problem seems to be that the (newer?) versions of ParseHeapDump.sh call the MemoryAnalyzer program directly, which in turn expects GTK+ to be there. I made my own version of ParseHeapDump.sh that does this instead: /tools/java/java/bin/java -Xmx16g -Xms16g -jar plugins/org.eclipse.equinox.launcher1.3.100.v201.jar -consoleLog -consolelog -application org.eclipse.mat.api.parse '$@' And that seems to work fine. (Substitute the location of your own 'java' for the /tools/java.

There are (at least) two separate Ant tasks that can take a JAR file and associated resources and build a.app bundle. The from java.net produces.app bundles that run on the Oracle Java 7 JRE and the produces bundles that run on the Java 6 supplied by Apple. But neither task will produce a.app that can run on both Java 6 and 7 because Oracle (7) and Apple (6) Javas use fundamentally different APIs for spawning the JVM from the launcher stub in the.app. If you want to be able to release your Java app to the Mac App Store then you have to use Java 7 and embed a copy of the JRE in the.app bundle (which appbundler can do for you).

Conversely, if you want your app to be runnable on Mac OS X version 10.6 or earlier then you need to use Java 6. Your comment on one of the other answers suggests that your app requires a native library.

Eclipse For Mac

You need to put this library inside the.app bundle along with your JAR. The.jnilib needs to go in Contents/Resources/Java for a Java 6 bundle (the same place as the JAR file), for a Java 7 bundle you specify the library in the fileset and it will be copied to the right place by appbundler ( Contents/MacOS).