Friday Dec 06, 2013

Java SE Embedded Pricing Explained

You're probably asking yourself, "Pricing?  Really?  In a techie blog?", and I would normally agree wholeheartedly with your assessment.  But in this one instance the topic might be worthy of a few words.  There is, as the expression goes, no such thing as a free lunch.  Whether you pay for software outright, or roll your own with open source projects, a cost must be paid.

Like clockwork, we regularly receive inquiries for Java embedded information that go something like this:

Dear Oracle,  We've downloaded and evaluated Java SE-Embedded and have found it to be a very appealing platform to run our embedded application.  We understand this is commercial software; before we decide to deploy our solution with your runtime, can you give us a feel for the royalties associated with shipping x number of units?

Seems pretty straightforward, right?  Well, yes, except that in the past Oracle required the potential customer to sign a non-disclosure agreement prior to receiving any embedded pricing information.  It didn't matter if the customer was interested in deploying ten units or ten thousand, they all had to go through this process.  Now certain aspects of pricing may still require confidential agreements, but why not make quantity 1 list prices available?   With the release of this document, that pricing information is now public.

The evidence is out there, both anecdotal and real, demonstrating that Oracle's Java SE-Embedded platform is unquestionably superior in quality and performance to the OpenJDK variants.  For the latest example, take a look at this blog entry.  So the question becomes, is it actually more affordable to pay for a commercial platform that is fully supported, faster and more reliable or to opt for a "free" platform and support it yourself.

So What Does Java SE-Embedded Cost?

The universal answer to such a question is: it depends.  That is to say it depends upon the capability of the embedded processor.  Before we lose you, let's show the list price for Java embedded licensing associated with three platforms and then explain how we arrived at the numbers.  As of the posting of this entry, 06 December, 2013, here they are:

  1. Per-unit cost for a Raspberry Pi: US $0.71
  2. Per-unit cost for system based on Intel Atom Z510P: US $2.68
  3. Per-unit cost for a Compulab Trim-Slice: US $5.36

How Does It Work?

These bullet points help describe the process, then we'll show how we arrived at our three sample platform prices.

  • Pricing is done on a per-core basis.
  • Processors are classified based on their capability and assigned a core factor.  The more capable the processor, the higher the core factor.
  • Per-core pricing is determined by multiplying the standard per-core Java embedded price by the core factor.
  • A 19% Software Update License & Support Fee is automatically added onto each system.

The core factor table that follows, found in the Oracle Java Embedded Global Price List, dated September 20, 2013, groups processors of similar capabilities into buckets called chip classes.  Each chip class is assigned a core factor.


Example 1

To compute the per-unit cost, use this formula:

Oracle Java Embedded per-core license fee  *  core factor  *  number of cores  *  support uplift

The standard per-core license fee is always $300.  The Raspberry Pi is a Class I device and therefore has a core factor of .002.  There is only one core in the Raspberry Pi, and the Software Update License & Support fee is always 19%.  So plugging in the numbers, we get:

$300  *  .002  *  1  *  1.19  =  $0.714

Example 2

The processor in this example, the Intel Atom Z510P, is a Class II device and has a core factor of .0075.  Using the same formula from Example 1, here's what we get:

$300  *  .0075  *  1  *  1.19  =  $2.6775

Example 3

The processor for the Trim-Slice is based on the ARM Cortex-A9, a Class II device.  Furthermore it is a dual-core system.  Using the same formula as the previous examples, we arrive at the following per-unit pricing:

$300  *  .0075  *  2  *  1.19  = $5.355

Conclusion

With your hardware specs handy, you should now have enough information to make a reasonable estimate of Oracle Java embedded licensing costs.  At minimum, it could be a help in your "buy vs. roll your own" decision making process.  And of course, if you have any questions, don't be afraid to ask.


Monday Oct 14, 2013

Oracle Java Now Part of Raspberry Pi Raspian Distribution

Having sold more than 1.75 million units in its brief lifespan, there is no denying the profound impact the Raspberry Pi has had on the embedded development community.  Amid all the hoopla surrounding the recently completed Oracle OpenWorld and Java One events, one announcement that flew under the radar dealt with the fact that the Oracle JDK is now part of the Raspberry Pi Raspian distribution.

This means that by default, when you download and install the latest Raspian distribution on your Raspberry Pi, the Oracle Java runtime environment and development tools are automatically part of the list of packages installed.  Here's a screenshot showing a login session to a Raspberry Pi running the 2013-09-25-wheezy-raspian distribution.  The JDK is installed as the oracle-java7-jdk package and is utilizing the Java 7u40 release.

For those who either cannot or do not wish to perform an entire Raspian upgrade, the Oracle JDK is available via the following command:

$ sudo apt-get update && sudo apt-get install oracle-java7-jdk

Great news.

Tuesday Sep 17, 2013

Comparing Linux/Arm JVMs Revisited

It's been about 18 months since we last compared Linux/Arm JVMs, and with the formal release of the much anticipated Java SE Embedded for Arm hard float binary, it marks a good time to revisit JVM performance.  The information and results that follow will highlight the following comparisons:

  1. Java SE-E Arm VFP (armel) vs. Arm Hard Float (armhf)
  2. Java SE-E armhf Client Compiler (c1) vs. armhf Server Compiler (c2)
  3. And last but certainly not least ... Java SE-E 7u40 armhf vs. Open JDK armhf

The Benchmark

For the sake of simplicity and consistency, we'll use a subset of the DaCapo benchmark suite.  It's an open source group of real world applications that put a good strain on a system both from a processor and memory workload perspective. We are aware of customers who use DaCapo to gauge performance, and due to its availability and ease of use, enables anyone interested to run their own set of tests in fairly short order.

The Hardware

It would have been grand to run all these benchmarks on one platform, most notably the beloved Raspberry Pi, but unfortunately it has its limitations:

  • There is no Java SE-E server compiler (c2) for the Raspberry Pi.  Why?  Because the Pi is based on an ARMv6 instruction set whereas the Java SE-E c2 compiler requires a minimum ARMv7 instruction set.
  • Demonstrating how rapidly advances are being made in the hardware arena, the Raspberry Pi, within the context of these tests, is quite a humble platform.  With 512MB RAM, it runs out of memory when running some of the large DaCapo component applications.
For these tests we'll primarily use a quad-core Cortex-A9 based system, and for one test we'll utilize a single core Marvell Armada system just to compare what effect the number of cores has on server compiler performance.  The devices in question are:
  1. Boundary Devices BD-SL-i.MX6, quad core 1GHz Cortex-A9 (Freescale i.MX6), 1GB RAM, Debian Wheezy distribution, 3.0.35 kernel (for both armel and armhf configurations)
  2. GlobalScale D2Plug, single core 800MHz ARMv6/v7 processor (Marvell PXA510), 1GB RAM, Debian Wheezy distribution, 3.5.3-cubox-di+ kernel for armhf

Java SE-E armel vs. armhf

The chart that follows compares the relative performance of the armel JavaSE-E 7u40 JRE with the armhf JavaSE-E 7u40 JRE for 8 of the DaCapo component applications.  These tests were conducted on the Boundary Devices BD-SL-i.MX6.  Both armel and armhf environments were based on the Debian Wheezy distribution running a 3.0.35 kernel.  For all charts, the smaller the result, the faster the run.

In all 8 tests, the armhf binary is faster, some only slightly, and in one case (eclipse) a few percentage points faster.  The big performance gain associated with the armhf standard deals with floating point operations, and in particular, the passing of arguments directly into floating point registers.  The performance gains realized by the newer armhf standard will be seen more in the native application realm than for Java SE-Embedded primarily because  the Java SE-E armel VM already uses FP registers for Java floating point methods.  There are still however certain floating point workloads that may show a modest performance increase (in the single digit percent range) with JavaSE-E armhf over Java SE-E armel.

Java SE-E Client Compiler (c1) vs. Server Compiler (c2)

In this section, we'll show tests results for two different platforms, the first a single core system, followed by the same tests on a quad-core system.  To further demonstrate how workload changes performance, we'll take advantage of the ability to run the DaCapo component applications in three different modes: small, default (medium) and large.  The first chart displays the aggregate time required to run the tests for the three modes, utilizing both the 7u40 client (c1) compiler and the server (c2) compiler.  As expected, c1 outperforms c2 by a wide margin for the tests that run only briefly.  As the total time to run the tests increases from small to large, the c2 compiler gets a chance to "warm up" and close the gap in performance.  But it never does catch up.  

Contrast the first chart with the one that follows where small, medium and large versions of the tests were run on a quad core system.  The c2 compiler is better able to utilize the additional compute resources supplied by this platform, the result being that initial gap in performance between c1 and c2 for the small version of the test is only 19%.  By the time we reach the large version, c2 outperforms c1 by 7%.  The moral of the story here is, given enough resources, the server compiler might be the better of the VMs for your workload if it is a long-lived process.

Java SE-E 7u40 armhf vs. Open JDK armhf

For this final section, we'll break out performance on an application-by-application basis for the following JRE/VMs:

  • Java SE Embedded 7u40 armhf Client Compiler (c1)
  • Java SE Embedded 7u40 armhf Server Compiler (c2)
  • OpenJDK 7 IcedTea 2.3.10 7u25-2.3.10-1~deb7u1 OpenJDK Zero VM (build 22.0-b10, mixed mode)
  • OpenJDK 7 IcedTea 2.3.10 7u25-2.3.10-1~deb7u1 JamVM (build 1.6.0-devel, inline-threaded interpreter with stack-caching)
  • OpenJDK 6 IcedTea6 1.12.6 6b27-1.12.6-1~deb7u1 OpenJDK Zero VM (build 20.0-b12, mixed mode)
  • OpenJDK 6 IcedTea6 1.12.6 6b27-1.12.6-1~deb7u1 JamVM (build 1.6.0-devel, inline-threaded interpreter with stack-caching)
  • OpenJDK IcedTea6 1.12.6 6b27-1.12.6-1~deb7u1 CACAO (build 1.6.0+r68fe50ac34ec, compiled mode)

The OpenJDK packages were pulled from the Debian Wheezy distribution.

It appears the bulk of performance work to OpenJDK/Arm still revolves around the OpenJDK 6 platform even though Java 7 was released over two years ago (and Java 8 is coming soon).  Regardless, Java SE still outperforms most OpenJDK tests by a wide margin, and perhaps more importantly appears to be the much more reliable platform considering the number of tests that failed with the OpenJDK variants.  As demonstrated in previous benchmark results, the older armel OpenJDK VMs appear to be more stable than the armhf versions tested here.  Considering the stated direction by the major linux distributions is to migrate towards the armhf binary standard, this is a bit eye opening.

As always, comments are welcome.



Tuesday Mar 15, 2011

The Unofficial Java SE Embedded SDK

Developing applications for embedded platforms gets simpler all the time, thanks in part to the tremendous advances in microprocessor design and software tools.  And in particular, with the availability of Java SE compatible Virtual Machines for the popular embedded platforms, development has never been more straightforward.

The real beauty behind Java SE Embedded development lies in the fact that you can use your favorite IDE (Eclipse, NetBeans, JDeveloper ...) to create, test and debug code in the identical fashion in which you'd develop a standard desktop or server application.  When the time comes to try it out on a Java SE Embedded capable device, it's just a matter of shipping the bytecodes over to the device and letting it run.  There is no need for complicated emulators, toolchains and cross-compilers.  The exact same bytecodes that ran on your PC, run unmodified on the embedded device.

In fact, because all versions of Java SE (embedded or not) share a considerable amount of common code, we have plenty of anecdotal evidence which supports the notion that behavior -- correct or incorrect -- manifests itself identically across platforms.  We refer specifically here to bugs.  Now no one wants bugs, but believe it or not, our customers like the fact that behavior is consistent across platforms whether it's right or not. "Bug for bug compatibility" has actually become a strong selling point!

Having espoused the virtues of transparently developing off device, many still wish to test and debug on-device regularly as part of their development cycle.  If you're the touchy/feely type, there are ample examples of affordable and supported off-the-shelf devices that could fit the bill for an Unofficial Java SE Embedded SDK.  One such platform is the Plug Computer.

The reference platform for the Plug Computer is supplied by Marvell Technology Group. Manufacturers then license the technology from Marvell to create their own specific implementations.  Two such vendors are GlobalScale and Ionics.  These are incredibly capable devices that include Arm processors in the 1.2GHz to 2.0GHz range, and sport 512MB of RAM and flash.  There are a host of external port and interface options including USB, µUSB, SATA, GBE, SD, WiFi, ZigBee, Z-Wave and soon HDMI.  Additionally, several Linux distros are available for these systems too.  The typical cost for a base model is $99, and perhaps the most disruptive aspect of these systems, they consume on average about 5 watts of power.

Alongside developing in the traditional manner, the ability to step through and examine state on these devices via remote debugging comes as a standard feature with the Java SE-E VM.  Furthermore, you can use the JConsole application from your desktop to remotely monitor performance and resource consumption on the device.

So what would a bill of materials look like for The Unofficial Java SE Embedded SDK?  Pretty simple actually:

That's about it.  Of course, for higher level functionality, you can add additional packages.  For example, Apache runs beautifully here.  Could anyone imagine a large number of these devices acting as a parallel web server?

Thursday Dec 16, 2010

Java SE Embedded Refreshed

As embedded processor designs continue their inexorable drive towards ever increasing capability, the natural desire to utilize more robust software platforms, previously reserved for powerful desktop computers and servers, follows suit.  Recognizing this trend, a version of the Java Standard Edition platform, called Java SE Embedded, has been developed to address this growing market.  In addition to bringing all of the benefits of the ubiquitous Java Standard Edition to the most popular embedded processors, static footprint and memory optimizations have been realized.  To get a feel for some of the space savings, check out this article.

Partly due to the turmoil surrounding the Oracle acquisition of Sun, a refresh of the Java SE Embedded binaries took longer than anticipated.  The new versions are now available for download with these supported configurations.  During that time frame, Java SE-E engineers were able take care of some internal housekeeping which should help for better synchronization of future releases of Java SE with Java SE-E.  In the past, Java SE-E engineers would take a snapshot of the Java Standard Edition code and incorporate their modifications to create a new release, forking from the standard edition source,.  Now, the Java SE-E code is part of the overall Java SE project, such that future Java SE enhancements and bug fixes should now be automatically incorporated into the Java SE-E code base.

The refreshed Java SE-E binaries are based on the Java SE 6 Update 21, and represent substantial security, performance and quality enhancements.  Benchmark tests show that, for example, simply replacing the previous versions of the Java SE-E virtual machines with the latest binaries produces on average about 20% performance gain for the same hardware/OS combination.  Having recently introduced a Just-In-Time (or JIT) compiler to the Android Dalvik Virtual Machine, we thought it would be an interesting exercise to compare performance of Java SE-E to Android on identical hardware.  For a full explanation of the results and methodology, check out Bob Vandette's blog on this topic.  To cut to the chase, for the selected benchmarks, Java SE-E outperforms Android by a factor of two. 

Improving virtual machine performance is a tedious process that takes time.  The bottom line is this:  Java SE Virtual Machine engineers have been at this for a very long time, and have had the benefit of fifteen years of scrutiny from the computer science community.  It will take considerable time and effort for Android to come close to this capability.  In the interim, the Java Virtual Machine performance and quality improvement marches on.

   Next up: Take a look at these pictures.  Based upon Marvell's Plug Computer design, these amazing devices pack a 1+GHz Arm processor with 512MB RAM and consume a minuscule 5 watts of power. They run Java SE-E beautifully.  Combined with an IDE like NetBeans, this makes for an ideal, although unofficial, Java SE Embedded Development Kit.

About

Jim Connors

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today