DZone
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
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
  1. DZone
  2. Coding
  3. Java
  4. 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 · Interview
Like (0)
Save
Tweet
Share
9.53K 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

  • Master Spring Boot 3 With GraalVM Native Image
  • Rust vs Go: Which Is Better?
  • [DZone Survey] Share Your Expertise and Take our 2023 Web, Mobile, and Low-Code Apps Survey
  • Monolithic First

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • 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: