Tuning Garbage Collection with the 5.0 Java[tm] Virtual Machine

Introduction The Java TM 2 Platform Standard Edition (J2SE TM platform) is used for a wide variety of applications from small applets on desktops to web services on large servers. In the J2SE platform version 1.4.2 there were four garbage collectors from which to choose but without an explicit choice by the user the serial garbage collector was always chosen. In version 5.0 the choice of the collector is based on the class of the machine on which the application is started. This “smarter choice” of the garbage collector is generally better but is not always the best. When does the choice of a garbage collector matter to the user? Amdahl observed that most workloads cannot be perfectly parallelized; some portion is always sequential and does not benefit from parallelism. The graph below models an ideal system that is perfectly scalable with the exception of garbage collection. The serial collector will be adequate for the majority of applications. Ergonomics for an application. Generations

Garbage Collection - Frequently Asked Questions This document describes the behavior of the Java( tm) HotSpot( tm) virtual machine. This behavior is not part of the VM specification, however, and is subject to change in future releases. Moreover the behavior described here is generic behavior and will not apply to the execution of all Java applications. How is the generational collector implemented in HotSpot(tm)? The default collector in HotSpot has two generations: the young generation and the tenured generation. The young generation collector is a copying collector. The tenured generation is collected with a mark-sweep-compact collection. What is the relevance of -XX:MaxNewSize? The young generation is set by a policy that bounds the size from below by NewSize and bounds it from above by MaxNewSize. Are all eden-space objects moved into the survivor space so that after a minor gc, eden-space is empty? Yes. When using -XX: TargetSurvivorRatio=90 will this leave ten percent of to-space for objects to be moved from eden? No.

Garbage Collection: ConcMarkSweep vs. RMI | Webapper Blog Abstract Use of the ConcMarkSweep garbage collector for the “tenured” generation is undesirable when RMI (Remote Method Invocation) garbage collection is occurring. Introduction Java doesn”t require that you explicitly release memory allocations in your program, which greatly reduces the time to build useful applications and eliminates most memory leaks. The challenge with user-facing applications (like Web application servers) is to make those pauses as brief as possible, with the goal that no user will notice them. Since most memory allocations are released almost immediately after they”re allocated, the Sun JVM uses a “generational” memory allocation and collection scheme to improve efficiency by focusing collection efforts on recently allocated memory. There are three main types of collections: 1. Full collections are expensive and tend to produce long pauses, so it”d be nice to be able to avoid them. Young Generation Collection Tenured Generation Collection Enter RMI

Performance Tuning Garbage Collection in Java This document is a summary or outline of Sun's document: Tuning Garbage collection with the 1.4.2 Hotspot JVM located here: 1.0 Introduction For many applications garbage collection performance is not significant Default collector should be first choice2.0 Generations Most straightforward GC will just iterate over every object in the heap and determine if any other objects reference it. This gets really slow as the number of objects in the heap increase GC's therefor make assumptions about how your application runs. Most common assumption is that an object is most likely to die shortly after it was created: called infant mortality This assumes that an object that has been around for a while, will likely stay around for a while. GC organizes objects into generations (young, tenured, and perm) This is important!

BigAdmin Submitted Article: Understanding Concurrent Mark Sweep Garbage Collector Logs High performance storage Oracle’s high performance enterprise storage is optimized for Oracle workloads and cloud with unmatched TCO for active storage, data protection, and archive. Leading, large-scale enterprises continue to choose Oracle storage to run their applications faster, provides superior protection against cyberattacks, and securely preserve their long-term data. Features