Skip to main content

Class Data Sharing

Class data sharing (CDS) a feature introduced in J2SE 5.0 reduces the startup time for Java
programming language applications.

When the JRE is installed on 32-bit platforms using the Sun provided installer, the installer loads a set of
classes from the system jar file into a private internal representation, and dumps that representation to a file,
called a "shared archive".Class data sharing is not supported in Microsoft Windows 95/98/ME.

During subsequent JVM invocations, the shared archive is memory-mapped in, saving the cost of loading those
classes and allowing much of the JVM's metadata for these classes to be shared among multiple JVM processes.

The primary motivation for including CDS in the 5.0 release is the decrease in startup time it provides.
CDS produces better results for smaller applications because it eliminates a fixed cost: that of loading
certain core classes. The smaller the application relative to the number of core classes it uses, the
larger the saved fraction of startup time.

The footprint cost of new JVM instances has been reduced in two ways. First, a portion of the shared archive,
currently between five and six megabytes, is mapped read-only and therefore shared among multiple JVM processes.
Previously this data was replicated in each JVM instance. Second, since the shared archive contains class data
in the form in which the Java Hotspot VM uses it, the memory which would otherwise be required to access the
original class information in rt.jar is not needed. These savings allow more applications to be run concurrently
on the same machine.

Regenerating Shared Archive

To regenerate the share archive use the following command:

java -Xshare:dump

Diagnostic information will be printed as the archive is generated.

Manually Controlling Class Data Sharing

The class data sharing feature is automatically enabled when conditions allow it to be used. The following command
line options are present primarily for diagnostic and debugging purposes and may change or be removed in future

Disable class data sharing.

Require class data sharing to be enabled. If it could not be enabled for various reasons, print an error message and exit.

The default; enable class data sharing whenever possible.


Popular posts from this blog

Drools - An overview

For Java based applications the most challenging part has always been the business logic maintenance, and pick any applications which you find complex and if we ask ourself how complex it would be moving forward, the answer will always be nX times.

What do we do ? Drools comes for Rescue as a Rule Engine.

Drools provides mechanism:

a. To write business logic in simple english language
b. Easy to maintain and very simple to extend
c. Reusability of logic by defining keywords in a DSL file and using them in DSLR file.

But be careful nothing comes free, everything takes cost in terms of memory and time space.

Use Drools if you really have :

a. Business logic which you think is getting cluttered with multiple if conditions because of variety of scenarios
b. You will have growing demand of increase in the complexity
c. The business logic changes would be frequent (1 - 2 times a year would also be frequent)
d. Your server's have enough of memory as it is a memory hungary tool, it provi…

MQTT - Eclipse Paho integration for Android

For MQTT integration, recently explored Paho Android project, very simple to use, here are the steps:

Intialize a client, set required options and connect.

    MqttAndroidClient mqttClient = new MqttAndroidClient(BaseApplication.getAppContext(), broker, MQTT_CLIENT_ID);
    //Set call back class
    mqttClient.setCallback(new MqttCallbackHandler(BaseApplication.getAppContext()));
    MqttConnectOptions connOpts = new MqttConnectOptions();
    IMqttToken token = mqttClient.connect(connOpts);

Subscribe to a topic.

    token.setActionCallback(new IMqttActionListener() {
      public void onSuccess(IMqttToken arg0) {
           mqttClient.subscribe("TOPIC_NAME" + userId, 2, null, new IMqttActionListener() {
                public void onSuccess(IMqttToken asyncActionToken) {
                    Log.d(LOG_TAG, "Successfully subscribed to topic.");

                public void onFailure…

Mobile Testing

Mobile application testing falls into broadly two types:

Hardware Testing This includes testing internal hardware, screen size, resolution, space, camera, Bluetooth, WIFI etc.
Software or Application Testing This includes testing the application that are running on device. Because of types of apps this can be divided into following categories: Native appsMobile web appsHybrid apps There are some key things to be considered when testing mobile apps: Native apps have single platformNative apps are written in platforms like SDKs while Mobile web are written in html, cssNative/Hybrid apps may or may not require internet connectionMobile web apps require internet connectionNative/Hybrid apps are downloaded from playstoreMobile web apps are accessible from internet Mobile Testing complexity in comparison web applications Different range of mobile devices, screen sizes etc.Various manufactures customizationsOS types iOS, Android, Windows etc.Different versions of OS e.g. Android 4.x, 5.x, 6.x, 7.x…