Printing Generated Assembly Code From The Hotspot JIT Compiler documented back in 2013 how to view Java Hotspot generated assembly code.
While still useful, the disassembler plugin referenced in the post is no longer available in binary form as the Kenai project has been decommissioned.
A number of references are available on how to build the plugin, however information on how to build on current macOS systems is hard to come by. Here is how to build the disassembler plugin on Java 10.
- macOS High Sierra 10.13
- Xcode 9.3 (including Command-line Tools)
- https://github.com/AdoptOpenJDK/jitwatch/wiki/Building-hsdis pointed out the requirement for binptils 2.26
- https://www.chrisnewland.com/updated-instructions-for-building-hsdis-on-osx-417 was a good starting point
- OpenJDK Supported platforms: https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
- OpenJDK Sources: http://jdk.java.net/java-se-ri/10
- java command line arguments: https://docs.oracle.com/javase/10/tools/java.htm
Martin Thompson first reported on the cost of contention using a simple benchmark that measures the time to increment a 64-bit counter 500 million times using various strategies. Results were reported here (section 3.1) and here (Managing Contention vs. Doing Real Work).
I re-implemented this benchmark here.
The results I observed (running on Java 9 with a 2017 MacBook Pro with a 2.9 GHz 7th Generation Kaby Lake Intel Core i7 processor) are comparable to those reported by Martin 7 years ago.
Kaby Lake, Java 10
|Single thread with volatile
|Single thread with CAS
|Single thread with synchronized
|Single thread with lock
|Two threads with CAS
|Two threads with synchronized
|Two threads with lock
While this micro-benchmark is not representative of real-world workloads (as explained here), tempted by its simplicity I plan to use it as the first benchmark to track optimizations to the air-java concurrency library. This would be followed up by a more comprehensive benchmark like this one, which measure both latency and throughput under various configurations, and finally a real-world application.
When starting a new Java project recently, I found it surprisingly difficult to setup the Gradle build with support for Java 9 modules and the Kotlin language.
For others who might find themselves in the same bind, here is a gist with the simplest, minimal gradle setup I came up with that includes:
- A multi-project gradle build,
- Java 9 modules support,
- IntelliJ IDEA integration,
- Kotlin language modules with support for cross-references between Java and Kotlin code in the same module.
Here is an proof-of-concept example of the above build scripts in action: https://github.com/nikolaybotevb/gradle-java9-kotlin.