Thursday Mar 24, 2016

G1: from garbage collector to waste management consultant

Java’s garbage collection capabilities make it easier for developers to write software and focus on the task at hand, without focusing on freeing up unused memory. In JDK 9, the G1 garbage collector will likely become the default collector and can do more than simply freeing memory. Instead of a simple garbage collector to free up memory, G1 takes the role of a waste management consultant: freeing unused memory and identifying ways to reduce the overall amount of garbage.

String Deduplication may decrease heap usage by about 10%

String objects are among the most commonly used object by almost all applications. Applications often store the same String multiple times for a variety of reasons, either within one class or across many classes. By analyzing these Strings, the JDK can decrease the overall memory needed to store them.String Deduplication may decrease heap usage by about 10%

String deduplication was first introduced in JDK 8 update 20 and operates as a background task. As the G1 garbage collector walks through memory references to clean up, it analyzes Strings to find duplicates and create memory-saving links between them. Similar to other garbage collection tasks, developers do not need to modify any code in order for it to work. An analysis by Fabian Lange from Codecentric found that String deduplication “adds no runtime overhead as it is performed asynchronously and concurrent during garbage collection.”

The following flags are needed to enable String Deduplication on JDK 8:

-XX:+UseG1GC Enables the G1 garbage collector.
-XX:+UseStringDeduplication Enables the String Deduplication feature within G1.
-XX:+PrintStringDeduplicationStatistics Optional flag to analyze what is happening through the command-line.
-XX:StringDeduplicationAgeThreshold=3 Optional flag to change when Strings become eligible for deduplication.

Example: Decreasing memory used by the Eclipse IDE

Eclipse is a popular Integrated Development Environment, helping developers read, write, and construct source code. The G1 garbage collector will typically perform better for long-running applications focused on throughput (e.g. servlet containers), but it can also function well for client applications.

The following example was run on JDK 8u72 with Eclipse Mars. I am also turning on a Java Flight Recording to see the impact on garbage collection, object allocation, and overall memory consumption. I ran the same operations twice: once without –XX:+UseStringDeduplication and the filename of before.jfr, so that I could do somewhat of a comparison.

The following lines can go inside your eclipse.ini at the end:The following lines can go inside your eclipse.ini at the end:

#The lines below are not necessary for G1, I am including them to benchmark the difference
-XX:StartFlightRecording=filename=after.jfr,dumponexit=true,maxage=5m,settings=c:/Users/ecostlow /desktop/Everything-Costlow.jfc

As a background task, String deduplication was taking about 0.0000908 seconds during my brief usage. It probably took longer to print statistics. Although my laptop is not a controlled environment and I manually did the same actions, the overall heap usage went down about 9% from 233MB to 213MB during my five minutes of usage.

JFR of G1 String Deduplication: before and after

Here are the details from the final output of the String Deduplication Statistics (using -XX:+PrintStringDeduplicationStatistics) with some cumulative numbers:

[GC concurrent-string-deduplication, 14.5K->6120.0B(8744.0B), avg 38.6%, 0.0000908 secs]
   [Last Exec: 0.0000908 secs, Idle: 0.8590383 secs, Blocked: 0/0.0000000 secs]
      [Inspected:             142]
         [Skipped:              0(  0.0%)]
         [Hashed:              89( 62.7%)]
         [Known:               21( 14.8%)]
         [New:                121( 85.2%)     14.5K]
      [Deduplicated:           96( 79.3%)   8744.0B( 58.8%)]
         [Young:                0(  0.0%)      0.0B(  0.0%)]
         [Old:                 96(100.0%)   8744.0B(100.0%)]
   [Total Exec: 52/0.1772395 secs, Idle: 52/103.0713572 secs, Blocked: 2/0.1476086 secs]
      [Inspected:          322160]
         [Skipped:              0(  0.0%)]
         [Hashed:          164740( 51.1%)]
         [Known:            61960( 19.2%)]
         [New:             260200( 80.8%)     20.3M]
      [Deduplicated:       144975( 55.7%)   8037.4K( 38.6%)]
         [Young:                2(  0.0%)     72.0B(  0.0%)]
         [Old:             144973(100.0%)   8037.3K(100.0%)]
      [Memory Usage: 4213.1K]
      [Size: 131072, Min: 1024, Max: 16777216]
      [Entries: 132446, Load: 101.0%, Cached: 3622, Added: 170306, Removed: 37860]
      [Resize Count: 7, Shrink Threshold: 87381(66.7%), Grow Threshold: 262144(200.0%)]
      [Rehash Count: 0, Rehash Threshold: 120, Hash Seed: 0x0]
      [Age Threshold: 3]
      [Dropped: 0]

Thursday Dec 18, 2014

Node.js and io.js on Java

The Nashorn JavaScript engine is one of many improvements in JDK 8. Nashorn (German for Rhino) is a faster replacement for the previous JavaScript engine known as Rhino. There is also another noteworthy feature: the ability to run many Node.js and io.js applications in the JVM. These applications can then call back and forth between optimized Java libraries and automatically receive monitoring capabilities through JMX.

In the upcoming JDK 8 update 40, it is planned to improve Nashorn / JavaScript performance even further through optimistic typing.

Java Virtual Machine - More than just Java

The Java Platform offers a way to run different types of applications, even if those applications are not written in the Java programming language. As a result, developers can take advantage of optimizations and stability of the JVM, while system administrators can better control and monitor deployments.

Examples of other languages on the JVM include: JavaScript (Nashorn), Ruby (JRuby), Python (Jython), Scala, Groovy, and many others.

Project Avatar – A JavaScript services layer on the JVM

Avatar.js is a project to bring the node programming model, APIs and module ecosystem to the Java platform. Although written in JavaScript, these applications can take advantage of the Java platform's scalability, manageability, tools, and extensive collection of Java libraries and middleware. After downloading the Avatar.js binaries, developers can then execute their applications. For example, Tim Caswell’s article "Hello Node!" contains basic examples for hello-console.js and hello-http.js that can be used as a basic way for testing Avatar.

Nashorn, The Hidden Weapon of JDK 8 was presented at the Silicon Valley Java User Group meeting in December 2014. The available slides describe the use of Nashorn and Avatar at Netflix and provide additional Nashorn demos.

Avoid rewrites and re-use libraries

One major benefit of running serverside JavaScript applications within the JVM is access to Java libraries. Developers do not have to rewrite major libraries or functionality like SQL or NoSQL drivers, Hadoop clients, encoding libraries, etc. Additional examples are available in a previous post, Nashorn: the rhino in the room, but they are not specific to Node.js.

Niko Köbler has a two-part article about Avatar 2.0 and its Model Store API. By using this model store API, developers can more easily interact with SQL and No-SQL and benefit from many existing optimizations.

  1. Part 1 explains the architecture and threading model.
  2. Part 2 covers the technology behind the Model Store API.

Monitoring Applications on the JVM

All Java processes can be monitored through a mechanism called JMX. System Administrators can enable remote authenticated JMX connections and see inside these running applications, rather than monitoring from the outside coming in.

Additional details about JMX monitoring (both local and remote) can be found in a previous post, Deep Monitoring with JMX.

Monitoring applications with Mission Control / Flight Recorder

Java Flight Recorder is an effective way of monitoring JVM applications in production. Unlike standard development profilers (like the NetBeans profiler), Flight Recorder has negligible performance impact.

The dashboard view in Mission Control provides basic information about CPU and memory resources. Developers may use the Threads tab to better understand system throughput, or if the application is blocking around any particular resources.

To open Mission Control, run the jmc command and connect to your Avatar application. The screenshot below shows Mission Control monitoring a Node.js application identified as

Monitoring Node.js on Java

Although the Node.js applications are written in JavaScript, Flight Recorder can also perform trigger-based recordings on events, such as a CPU spike. System Administrators and Developers can look back at the recording to see what lead up to the event.

Additional details are available on the Mission Control home page and user guide.

Additional ways of running Node.js on the JVM

Avatar is one of several ways to run Node.js applications on the JVM.

When run on Oracle Java, both projects can be monitored by Flight Recorder / Mission Control as described above. Because this monitoring is provided directly by the Oracle JVM itself, there is no need to make any code changes or apply additional monitoring packages.

Monday Aug 11, 2014

Keeping users on Internet Explorer up-to-date and secure

New features announced by Microsoft give Internet Explorers users, developers and sysadmins more tools to keep users of Java up to date and secure.[Read More]

Wednesday Jun 11, 2014

Nashorn, the rhino in the room

Nashorn is a new runtime within JDK 8 that allows developers to run code written in JavaScript and call back and forth with Java. One advantage to the Nashorn scripting engine is that is allows for quick prototyping of functionality or basic shell scripts that use Java libraries. The previous JavaScript runtime, named Rhino, was introduced in JDK 6 (released 2006, end of public updates Feb 2013). Keeping tradition amongst the global developer community, "Nashorn" is the German word for rhino.

The Java platform and runtime is an intentional home to many languages beyond the Java language itself. OpenJDK’s Da Vinci Machine helps coordinate work amongst language developers and tool designers and has helped different languages by introducing the Invoke Dynamic instruction in Java 7 (2011), which resulted in two major benefits: speeding up execution of dynamic code, and providing the groundwork for Java 8’s lambda executions. Many of these improvements are discussed at the JVM Language Summit, where language and tool designers get together to discuss experiences and issues related to building these complex components.

There are a number of benefits to running JavaScript applications on JDK 8’s Nashorn technology beyond writing scripts quickly:

  1. Interoperability with Java and JavaScript libraries.
  2. Scripts do not need to be compiled.
  3. Fast execution and multi-threading of JavaScript running in Java’s JRE.
  4. The ability to remotely debug applications using an IDE like NetBeans, Eclipse, or IntelliJ (instructions on the Nashorn blog).
  5. Automatic integration with Java monitoring tools, such as performance, health, and SIEM.

In the remainder of this blog post, I will explain how to use Nashorn and the benefit from those features.

Nashorn execution environment

The Nashorn scripting engine is included in all versions of Java SE 8, both the JDK and the JRE. Unlike Java code, scripts written in nashorn are interpreted and do not need to be compiled before execution.

Developers and users can access it in two ways:

  • Users running JavaScript applications can call the binary directly:
    • This mechanism can also be used in shell scripts by specifying a shebang like #!/usr/bin/jjs
  • Developers can use the API and obtain a ScriptEngine through:
    ScriptEngine engine = new ScriptEngineManager().getEngineByName("nashorn");
    • When using a ScriptEngine, please understand that they execute code. Avoid running untrusted scripts or passing in untrusted/unvalidated inputs. During compilation, consider isolating access to the ScriptEngine and using Type Annotations to only allow @Untainted String arguments.

One noteworthy difference between JavaScript executed in or outside of a web browser is that certain objects will not be available. For example when run outside a browser, there is no access to a document object or DOM tree. Other than that, all syntax, semantics, and capabilities are present.

Examples of Java and JavaScript

The Nashorn script engine allows developers of all experience levels the ability to write and run code that takes advantage of both languages. The specific dialect is ECMAScript 5.1 as identified by the User Guide and its standards definition through ECMA international.

In addition to the example below, Benjamin Winterberg has a very well written Java 8 Nashorn Tutorial that provides a large number of code samples in both languages.

Basic Operations

A basic Hello World application written to run on Nashorn would look like this:

print("Hello World");

The first line is a standard script indication, so that Linux or Unix systems can run the script through Nashorn. On Windows where scripts are not as common, you would run the script like: jjs helloWorld.js.

Receiving Arguments

In order to receive program arguments your jjs invocation needs to use the -scripting flag and a double-dash to separate which arguments are for jjs and which are for the script itself:
jjs -scripting print.js -- "This will print"

var whatYouSaid = $ARG.length==0 ? "You did not say anything" : $ARG[0]

Interoperability with Java libraries (including 3rd party dependencies)

Another goal of Nashorn was to allow for quick scriptable prototypes, allowing access into Java types and any libraries. Resources operate in the context of the script (either in-line with the script or as separate threads) so if you open network sockets and your script terminates, those sockets will be released and available for your next run.

Your code can access Java types the same as regular Java classes. The “import statements” are written somewhat differently to accommodate for language. There is a choice of two styles:

  1. For standard classes, just name the class: var ServerSocket =
  2. For arrays or other items, use Java.type: var ByteArray = Java.type("byte[]")
    You could technically do this for all.

The same technique will allow your script to use Java types from any library or 3rd party component and quickly prototype items.

Building a user interface

One major difference between JavaScript inside and outside of a web browser is the availability of a DOM object for rendering views. When run outside of the browser, JavaScript has full control to construct the entire user interface with pre-fabricated UI controls, charts, or components. The example below is a variation from the Nashorn and JavaFX guide to show how items work together.

Nashorn has a -fx flag to make the user interface components available. With the example script below, just specify: jjs -fx -scripting fx.js -- "My title"

#!/usr/bin/jjs -fx
var Button = javafx.scene.control.Button;
var StackPane = javafx.scene.layout.StackPane;
var Scene = javafx.scene.Scene;
var clickCounter=0;
$STAGE.title = $ARG.length>0 ? $ARG[0] : "You didn't provide a title";
var button = new Button();
button.text = "Say 'Hello World'";
button.onAction = myFunctionForButtonClicking;
var root = new StackPane();
$STAGE.scene = new Scene(root, 300, 250);
function myFunctionForButtonClicking(){
  var text = "Click Counter: " + clickCounter;

For a more advanced post on using Nashorn to build a high-performing UI, see JavaFX with Nashorn Canvas example.

Interoperable with frameworks like Node, Backbone, or Facebook React

The major benefit of any language is the interoperability gained by people and systems that can read, write, and use it for interactions. Because Nashorn is built for the ECMAScript specification, developers familiar with JavaScript frameworks can write their code and then have system administrators deploy and monitor the applications the same as any other Java application.

A number of projects are also running Node applications on Nashorn through Project Avatar and the supported modules.

In addition to the previously mentioned Nashorn tutorial, Benjamin has also written a post about Using Backbone.js with Nashorn.

To show the multi-language power of the Java Runtime, there is another interesting example that unites Facebook React and Clojure on JDK 8’s Nashorn.


Nashorn provides a simple and fast way of executing JavaScript applications and bridging between the best of each language. By making the full range of Java libraries to JavaScript applications, and the quick prototyping style of JavaScript to Java applications, developers are free to work as they see fit.

Software Architects and System Administrators can take advantage of one runtime and leverage any work that they have done to tune, monitor, and certify their systems.

Additional information is available within:

Thursday Apr 17, 2014

Secure Coding Guidelines for Java SE

With so much happening around the Java platform, it’s understandable if you missed the recent improvements we made to the Secure Coding Guidelines for Java SE.  In January 2014 the Java Platform Group released a significant update, Java 7 Update 51 establishing code-signing as the default for Applets and Web Start applications.  Following in March 2014, we hit another major milestone with the long anticipated release of Java SE 8.

There are a number of improvements to the Secure Coding Guidelines for Java SE.  On the surface, the larger domains of the coding guidelines like Fundamentals and Denial of Service are the same but content has been improved throughout each domain based upon changes to Java’s threat landscape.  Likewise, small but noteworthy improvements to content navigation were made to the domains in table of contents facilitating quick navigation for readers.

Beyond content improvements, code examples were refreshed to highlight new Java 8 features like Lambda.  While our coding guidelines are updated for Java SE 8, most guidance is relevant to older versions like Java SE 7.  Please keep in mind secure application coding and design is only one component in a secure solution.  Building secure solutions requires OS security hardening, application and infrastructure hardening, patching all components on a timely schedule, etc.  More information about Java security is available in the Security Resource Center for Java.


Science Duke
This blog contains topics related to Java SE, Java Security and Usability. The target audience is developers, sysadmins and architects that build, deploy and manage Java applications. Contributions come from the Java SE Product Management team.


« June 2016