JVM

Application freezes - too many full GC's

 

elad 05/01/2010 - 16:37
Distributed RMI, Full GC, Java, JVM, jvm
32-bit JVM vs. to 64-bit JVM on Windows - upgrade implications
This post discusses the reasons for moving to 64-bit VM and the performance characteristics of 64-bit machine vs. 32-bit VMs
It's based on the HotSpot VM FAQ (http://java.sun.com/developer/technicalArticles/Programming/HPROF.html) .

On a 32-bit Windows systems, the maximum heap size per Java VM process ranges between 1.5 to 1.6 GB (in practice).
You can see the explanation here: 32-bit Windows and JVM virtual memory limit (http://sinewalker.wordpress.com/2007/03/04/32-bit-windows-and-jvm-virtua...)

If your application requires a larger heap, you should use a 64-bit VM. The primary advantage of running Java in a 64-bit environment is the larger address space.
This allows for a larger Java heap size and an increased maximum number of Java Threads.
It's important to note that 64-bit implementation doesn't mean that that built-in Java types (such as integers) are doubled in size from 32 to 64.
elad 08/09/2009 - 11:21
32-bit JVM, 64-bit JVM, JVM, upgrade to 64-bit
Checking the health of the heap using GC verbosity

elad 29/08/2009 - 13:18
Garbage Collection, GC, JVM, old generation, tenured, young generation
Performance tunning case study

Recently I had the chance to help one of our clients (company XXX) analyze and detect performance issues. Below are the main issues raised during the consultation session and the recommended course of action for each problem. I am presenting these here for the benefit of other employees who might be needed to do the same type of consulting.


General background: company XXX reported several problems, mainly related to high memory consumption and thread exhaustion, with respect to their product at one of their largest clients web site.

shlomo 03/06/2009 - 10:38
JVM
Garbage Collection: Serial vs. Parallel vs. Concurrent-Mark-Sweep

 

elad 27/01/2010 - 17:40
CMS, Concurrent-Mark-Sweep, Garbage Collection, GC, Java, JVM, parallel
Java group meeting: Java performance tuning

The event titled "Java performance tuning (tools) and Java code optimization", is intended to cover a varied array of topics ranging from basic java code optimization to tuning large scale JVMs, heaps and application servers (Jboss, tomcat,Jetty) on multi-core CPUs, 32 and 64 BIT operating systems. 

An effort will be made to introduce the most frequently used tools for JVM memory and thread profiling and monitoring such as jstat, jconsole, jhat, jproiler/yourkit/MAT, VisualVM etc.

In addition a real world example will be presented in order to demonstrate and discuss the tools and profiling methodologies used.


On a side note, this will unsurprisingly be a highly technical session and is intended mostly (though not exclusively) for veteran Java developers.

 

shlomo 18/01/2010 - 22:44
Heap, JVM, OOM, optimization, Profiling
JVM languages Google groups thread

 http://groups.google.com/group/jvm-languages/browse_thread/thread/2c10bde4b9985086?pli=1

adi 20/11/2009 - 23:40
Java, JSE7, JVM, Scala
Monitoring Garbage Collector's time stamps using the GarbageCollectorMXBean

This post shows how to print to the GC log a summary of minor and full garbage collections:
 
It's done by creating a thread that uses the GarbageCollectorMXBean.
The result of this thread is printing to the GC log (each pre-defined time) a summary of the minor and full collections that were performed in that time.
 
For example, the following line:
2007-09-28 17:03:59,037 [84.80] Minor GC x 6, 22 millisecs
represents 6 minor collections that took 22 milliseconds.

 

elad 30/08/2009 - 15:51
Garbage Collector, JVM, MXBean
Trick the eye

I admit I was tricked:

 

import java.util.ArrayList;
public class ListProvider {
  public static <ArrayList> ArrayList getList(ArrayList ar) {
    return ar;
  }
  public static void main(String[] args) {
      getList("I am a list");
  }
}

This code compiles and runs of course.

shlomo 22/06/2009 - 21:53
code obfuscation, Compiler, JVM
BTrace is a safe, dynamic tracing tool for the Java platform

BTrace is a safe, dynamic tracing tool for the Java platform. BTrace can be used to dynamically trace a running Java program (similar to DTrace for OpenSolaris applications and OS). BTrace dynamically instruments the classes of the target application to inject tracing code ("bytecode tracing"). Tracing code is expressed in Java programming language. There is also integration with DTrace for the OpenSolaris platform.

lior.kanfi 03/06/2009 - 22:09
JVM, tuning performance tracing
Syndicate content