days
-4
-3
hours
0
-2
minutes
-5
-1
seconds
-5
-7
search
Time for some enhancements

JDK 12 patrol: Microbenchmark Suite targeted to JDK 12

JAX Editorial Team
jdk12
© Shutterstock /Stephen Plaster  

The tech world is moving fast and we’re in for the ride! The JDK 12 development repositories are open and we thought it’s time to start a new thread in order to keep track of everything that’s going live. Today we have only but a small updated with Microbenchmark Suite becoming targeted to JDK 12.

A new era began with the release of JDK 10. It’s already been two months since we moved on even further with the release of Java SE 11 (JDK 11), the first LTS release in Oracle’s new six-month cycle.

You can download Java 11 here.

That being said, JDK 12 is not set up for release yet, but the development repositories are open for bug fixes, small enhancements, and JEPs so it is time for a new thread to keep track of everything that goes live.

And since JDK 11 featured 3 JEP contributions from the community (the largest number of community contributions to a release so far) let’s keep up the pace!

Here’s the small update we have for today.

Targeted to JDK 12

Summary: Add a basic suite of microbenchmarks to the JDK source code, and make it easy for developers to run existing microbenchmarks and create new ones.

Goals:

  • Based on the [Java Microbenchmark Harness (JMH)][1]
  • Stable and tuned benchmarks, targeted for continuous performance testing
    • A stable and non-moving suite after the Feature Complete milestone of a feature release, and for non-feature releases
    • Support comparison to previous JDK releases for applicable tests
  • Simplicity
    • Easy to add new benchmarks
    • Easy to update tests as APIs and options change, are deprecated, or are removed during development
    • Easy to build
    • Easy to find and run a benchmark
  • Support JMH updates
  • Include an initial set of around a hundred benchmarks in the suite

JEPs targeted to JDK 12 so far

 

Update November 12, 2018

JEP candidates

JEP 344: Abortable Mixed Collections for G1

Summary: Make G1 mixed collections abortable if they might exceed the pause target.

Motivation: One of the goals of G1 is to meet a user-supplied pause time target for its collection pauses.

Non- goals: Make all pauses in G1 abortable.

JEP 345: NUMA-Aware Memory Allocation for G1

Summary: Improve G1 performance on large machines by implementing NUMA-aware memory allocation.

Motivation: Large enterprise applications, in particular, tend to run with large heap configurations on multiple sockets, yet they want the manageability advantage of running within a single JVM. We are seeing customers using the G1 collector increasingly running up against this scaling bottleneck.

Non- goals: 

  • Support for other collectors than G1.
  • Support for other OSes than Linux and Solaris.
  • NUMA-awareness of other parts of the G1 collector like task queue stealing remembered sets or refinement.

JEP 346: Promptly Return Unused Committed Memory from G1

Summary: Enhance the G1 garbage collector to automatically return Java heap memory to the operating system when idle.

Motivation: Currently the G1 garbage collector may not return committed Java heap memory to the operating system in a timely manner. G1 only returns memory from the Java heap at either a full GC or during a concurrent cycle.

Non-Goals:

  • Sharing of committed but empty pages between Java processes. Memory should be returned (uncommitted) to the operating system.
  • The process of giving back memory does not need to be frugal with CPU resources, nor does it need to be instantaneous.
  • Use of different methods to return memory other than available uncommit of memory.
  • Support for other collectors than G1.

 

Update November 5, 2018

Proposed to target JDK 12

Summary: Add a basic suite of microbenchmarks to the JDK source code, and make it easy for developers to run existing microbenchmarks and create new ones.

Goals:

  • Based on the [Java Microbenchmark Harness (JMH)][1]
  • Stable and tuned benchmarks, targeted for continuous performance testing
    • A stable and non-moving suite after the Feature Complete milestone of a feature release, and for non-feature releases
    • Support comparison to previous JDK releases for applicable tests
  • Simplicity
    • Easy to add new benchmarks
    • Easy to update tests as APIs and options change, are deprecated, or are removed during development
    • Easy to build
    • Easy to find and run a benchmark
  • Support JMH updates
  • Include an initial set of around a hundred benchmarks in the suite

 

Update October 11, 2018

Today we add two more JEPs to the targeted to JDK 12 list and we see the implementation of JEP 341 been pushed into jdk/jdk repository.

Let’s have a closer look.

Targeted to JDK 12

JEP 325: Switch Expressions (Preview)

Summary: Extend the switch statement so that it can be used as either a statement or an expression, and that both forms can use either a “traditional” or “simplified” scoping and control flow behavior. These changes will simplify everyday coding, and also prepare the way for the use of pattern matching (JEP 305) in switch. This will be a preview language feature.

Motivation: As we prepare to enhance the Java programming language to support pattern matching (JEP 305), several irregularities of the existing switch statement — which have long been an irritation to users — become impediments. These include the default control flow behavior (fall through) of switch blocks, the default scoping of switch blocks (the block is treated as one single scope) and that switch works only as a statement, even though it is commonly more natural to express multi-way conditionals as expressions.

The current design of Java’s switch statement follows closely languages such as C and C++, and supports fall-through semantics by default. Whilst this traditional control flow is often useful for writing low-level code (such as parsers for binary encodings), as switch is used in higher-level contexts, its error-prone nature starts to outweigh its flexibility. We propose to introduce a new form of switch label, written “case L ->” to signify that only the code to the right of the label is to be executed if the label is matched.

JEP 326: Raw String Literals (Preview)

Summary: Add raw string literals to the Java programming language. A raw string literal can span multiple lines of source code and does not interpret escape sequences, such as \n, or Unicode escapes, of the form \uXXXX. This will be a preview language feature.

Goals

  • Make it easier for developers to
    • express sequences of characters in a readable form, free of Java indicators,
    • supply strings targeted for grammars other than Java, and
    • supply strings that span several lines of source without supplying special indicators for new lines.
  • Raw string literals should be able to express the same strings as traditional string literals, except for platform-specific line terminators.
  • Include library support to replicate the current javac string-literal interpretation of escapes and manage left-margin trimming.

Non-Goals

  • Do not introduce any new String operators.
  • Raw string literals do not directly support string interpolation. Interpolation may be considered in a future JEP.
  • No change in the interpretation of traditional string literals in any way, including:
    • multi-line capability,
    • customization of delimiters with repeating open and close double-quotes, and
    • handling of escape sequences.

In addition to JEPs 325 and 326 being targeted to JDK 12, the implementation of JEP 341 has been pushed into jdk/jdk repository.

 

Update  

Targeted to JDK 12

JEP 340: One AArch64 Port, Not Two

Summary: Remove all of the sources related to the arm64 port while retaining the 32-bit ARM port and the 64-bit aarch64 port.

Tasks to be completed as part of this JEP:

  • Remove all arm64-specific sources and #ifdefs related to 64-bit versus 32-bit builds in open/src/hotspot/cpu/arm
  • Scan the remaining JDK sources for #ifdefs related to this port
  • Remove the build option for building this port. Make the aarch64 port the default build for the 64-bit ARM architecture.
  • Validate that the remaining 32-bit ARM port continues to build and run the conformance tests with no regressions that did not exist prior to the changes related to this JEP.

JEP 341: Default CDS Archives

Summary: Enhance the JDK build process to generate a class data-sharing (CDS) archive, using the default class list, on 64-bit platforms.

Goals

  • Improve out-of-the-box startup time
  • Eliminate the need for users to run -Xshare:dump to benefit from CDS

Non-Goals

  • We will generate the default archive only for native builds, not for cross-compiled builds.
  • We will generate the default archive only for 64-bit builds; support for 32-bit builds may be added later.

JEP drafts

JEP draft: Support ByteBuffer mapped over non-volatile memory

Summary: Allow MappedByteBuffers to be mapped over non-volatile memory with writes committed via an efficient cache line flush.

JEP draft: Implement C++14 Language Features

Summary: Introduce C++14 compliant language features into HotSpot C++ source code.

 

Update September 17, 2018

JEP candidates

JEP 340: One AArch64 Port, Not Two

Summary: Remove all of the sources related to the arm64 port while retaining the 32-bit ARM port and the 64-bit aarch64 port.

JEP 341: Default CDS Archives

Summary: Enhance the JDK build process to generate a class data-sharing (CDS) archive, using the default class list, on 64-bit platforms.

JEP 342: Limit Speculative Execution

Summary: Help developers and deployers defend against speculative-execution (“Spectre”) vulnerabilities by providing a means to limit speculative execution, and enable further mitigations to be implemented in future releases.

JEP 343: Packaging Tool

Summary: Create a new tool for packaging self-contained Java applications. The jpackager tool will take as input a Java application and a Java run-time image, and produce a Java application image that includes all the necessary dependencies.

 

Update September 5, 2018

Proposed to target

Granted, two features may not seem like much but we’re just getting started!

JEP 325: Switch Expressions (Preview)

Summary: Extend the switch statement so that it can be used as either a statement or an expression, and that both forms can use either a “traditional” or “simplified” scoping and control flow behavior. These changes will simplify everyday coding, and also prepare the way for the use of pattern matching (JEP 305) in switch. This will be a preview language feature.

SEE ALSO: “Developers will see Java 11 as a better, cleaner implementation of the features they use in Java 8”

JEP 326: Raw String Literals (Preview)

Summary: Add raw string literals to the Java programming language. A raw string literal can span multiple lines of source code and does not interpret escape sequences, such as \n, or Unicode escapes, of the form \uXXXX. This will be a preview language feature.

While we are on the JDK 12 topic, don’t miss our interview series about Project Skara. What do you think is the most beneficial alternative SCM and code review for the JDK source code? Check out what the experts had to say.

The results of the JAXenter poll seem to be pretty clear. Git wins. That’s it. No further explanation needed.

On the other hand, the three interviews we had with Java experts paint a not-so-crystal-clear picture. Let me explain.

In the first interview, we talked to Java Champion and JavaOne Rock Star speaker Stephen Colebourne, who seems to be rather enthusiastic about the prospect of migrating JDK source code management to Git.

From my perspective, I think using Git instead of Mercurial is a great idea. I can’t see any case to move to any other SCM.

Stephen Colebourne

However, for our second interview, we caught up with OpenJDK Author Patrick Reinhart who based his view mostly on the popularity of Git as opposed to Mercurial.

For new contributors, Git seems to be more tool-friendly than Mercurial is at the moment.

Patrick Reinhart

For our last interview, that went online just yesterday, we talked to OpenJDK committer Thomas Stüfe, who seems to have a rather conservative opinion on the matter.

 I see no pressing technical reasons to switch to Git. I work with both SCMs and to me, none has a clear lead in performance or functionality.

Thomas Stüfe

See all the interviews here: 

zgqwzg

    DevOpsCon Whitepaper 2018

    Free: BRAND NEW DevOps Whitepaper 2018

    Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

uzqwg

Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of