DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > Reduced Footprint Java SE: Bringing Java Standard Edition Down to Size

Reduced Footprint Java SE: Bringing Java Standard Edition Down to Size

Jim Connors user avatar by
Jim Connors
·
Apr. 01, 08 · Java Zone · Interview
Like (0)
Save
Tweet
9.25K Views

Join the DZone community and get the full member experience.

Join For Free

A previous post on my blog demonstrated how you can, with minimal effort, lessen the disk footprint of a typical Java SE 5.0 runtime environment by about a third without violating the Java Standard Edition Licensing agreement. That post focused primarily on removing optional files and compressing class library jar files. It turns out that with a little more engineering, there is significant opportunity for further space optimization.

These additional savings involve more intimate knowledge of the inner workings of Java SE. Sun performs this engineering work and provides a series of reduced footprint versions of Java SE, in binary form, for some of the most common embedded platforms. They include some of these enhancements:

Headless configuration

The inclusion of graphics subsystems like AWT and Swing comprise a large chunk of the Java SE footprint. If your device has no graphics capability (i.e. is headless) why would you need to include this functionality? Headless configurations:

  • Do not support keyboard or mouse input
  • Cannot create windows or display graphics
  • Throw a HeadlessException when a graphics API is called
  • Still support a functional Java 2D API for printing and off-screen rendering
  • Are still 100% Java SE compatible

Eliminate client or server compiler

Sun's Java SE implementations include two HotSpot compilers, tuned and designed for specific environments. The client compiler focuses on things like fast user interactivity and quick startup, while the server compiler's priority is on optimizing large, long-lived server applications. The Java SE VM can only use one of these compilers at a time, so removing the unused one can save considerable space.

Minimizes memory consumption

Standard Java SE allocates RAM to house things like the JIT code cache and the object heap. By default, each one of these areas (and others) can be assigned 64 MB. In an embedded platform where the total amount of RAM might only be 64MB, Java SE will simply not have enough memory to run. Java SE Embedded on the other hand, will automatically adapt memory usage to the amount of available RAM. Consequently, 64MB is a reasonable amount of RAM for a large set of embedded Java applications.

Space vs. speed tradeoffs

(1) Java SE implements a thread lookup table, which in layman's terms, helps save a few instructions when switching between Java threads. By eliminating this table, a couple of MBs of RAM can be spared from your application's working set.

(2) Java SE also sets aside an area (mmap'ed) for loading jar files into random access memory, which as was explained to me, may help performance, but may also result in duplicate copies of jar files in memory. Removal of this area further reduces the Resident Set Size.

An Example

Following through with the exmaple in the last post., let's start with an unmodified version of Java SE 5.0 Update 13 for Linux/x86. By default, the static footprint is approximately 88MB.

   jimc@jalopy:/tmp> du -sk ./jre1.5.0_13/
   88185   ./jre1.5.0_13/

After following the directions in the previous post, we can pare it down to roughly 60MB.

   jimc@jalopy:/tmp> du -sk /tmp/jre1.5.0_13/
59358 /tmp/jre1.5.0_13/

Downloading Sun's reduced footprint version of Java SE for x86/Linux yields:

   jimc@jalopy:/tmp> du -sk /tmp/jre1.5.0_10/
31003 /tmp/jre1.5.0_10/

This version of the JRE is about one-third it's original size, and furthermore has been modified to use significantly less memory than the standard Java SE offerings. Note: we are comparing slightly different updates of Java SE 1.5 (update 13 vs. update 10). They are indeed not identical but their differences should be considered, for the sake of argument, negligible.

[1] Many thanks to Bob Vandette, who though presentation and conversation, supplied this information. One of many sources comes from Bob's Java ONE 2007 session called, Deploying Java Platform Standard Edition (Java SE Platform) in Today's Embedded Devices (TS-2602)

Thanks to Jim Connors for allowing the republishing of this article on JavaLobby.

Java (programming language)

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How to Build Microservices With Node.js
  • Container Orchestration Tools Comparison
  • Writing Beautiful, Optimized, and Better .NET Code With NDepend Static Analysis
  • How to Make Git Forget a Tracked File Now in .gitignore

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo