Andrew Dinn

Recent Posts

Debugging GraalVM-native images using gdb

Debugging GraalVM-native images using gdb

The GraalVM project includes, amongst other capabilities, a component called GraalVM Native Image. GraalVM Native Image supports the delivery of Java applications as shrink-wrapped, self-contained, standalone executables, commonly referred to as Java-native images. Native images often have a smaller footprint and faster startup time compared to running the same application in the traditional way on the JVM. This is often a win for short-running applications or small, container-based services. The trade-off is usually lower peak performance for long-running programs, and higher garbage collection overheads and latencies for programs with large amounts of resident data.

We are especially interested in GraalVM-native images as an alternative back-end delivery option for applications based on Quarkus. The Java team has worked hard to ensure that Quarkus is well integrated with GraalVM Native Images. In the process, they have found that one important usability issue is the ability to debug the delivered native image.

Continue reading “Debugging GraalVM-native images using gdb”

Share
Diagnosing Java applications on the fly with Byteman

Diagnosing Java applications on the fly with Byteman

Production being affected by software issues is always an unwanted scenario. Diagnosing production issues, however, should never be an unplanned activity. Structured testing and QA efforts would ideally prevent any software bugs from entering production. So the dilemma is how to prepare for something unexpected in production that was not considered during the earlier testing and QA phases.

This article discusses Byteman, a tool that leverages the Java Instrumentation API to inject Java code into methods without the need to recompile, repackage, or even redeploy the application.

Continue reading “Diagnosing Java applications on the fly with Byteman”

Share

Video: Monitoring application events in Thermostat, using Byteman

Thermostat is Red Hat’s Monitoring and management tool for Java Deployments, allowing users to measure and monitor a host of different performance aspects of their Java applications. Available metrics range from raw CPU and memory usage to operation of the Garbage Collector and Compiler through to thread activity and method call/heap profiles. Thermostat provides a GUI view of activity of local and distributed JVMs in real time and it also backs up all the metrics it obtains to a persistent store so they can be reviewed offline.

What Thermostat cannot do on its own is track events and record statistics that are specific to a given Java application, at least not unless the application co-operates with it, for example by publishing JMX statistics that Thermostat can read, persist and display in its GUI. However, that’s about to change thanks to work Red  Hat’s OpenJDK team has been doing to integrate Byteman into Thermostat.

Byteman is a tool which can be used to modify the behaviour of Java programs by injecting extra Java code almost anywhere in the program. You don’t need to recompile your program or even prepare it in advance in order for this to work. You can specify changes to the program on the command line but, what is more amazing, you can actually use Byteman to change the way a program runs after startup while it is still running.

Continue reading “Video: Monitoring application events in Thermostat, using Byteman”

Share

What Lies Beneath: A tour of the dark gritty underbelly of OpenJDK

java icon 240 × 171OpenJDK is the premier open source Java implementation. The OpenJDK project provides the code used to build Red Hat’s Java releases for Fedora and RHEL and the Java releases used on most other Linux distributions. It also forms the basis of Oracle’s proprietary Java binary releases.

The Red Hat OpenJDK team has been working for some time now, along with organizations like the London Java Community (LJC) and some of our academic partners (e.g. Glasgow & Manchester) to encourage researchers and developers to dive into the innards of OpenJDK’s Java Virtual Machine (JVM) and see how it actually works. One reason is the entirely selfish one that we would like to enlarge the community of potential contributors to the OpenJDK project. Another is that we think it is no bad thing for Java developers, as indeed for any developers, to understand the tools they are using at a deeper level and appreciate how a well designed tool shields them from having to manage some of the more complex aspects of the runtime environment in which their programs execute.

Continue reading “What Lies Beneath: A tour of the dark gritty underbelly of OpenJDK”

Share

Dude, where’s my PaaS memory? Tuning Java’s footprint in OpenShift (Part 2)

Continued from part 1.

The test web service

The test web service implements a simple file cache storing up to 10 copies of any given named file. Uploading copies beyond the 10th one causes the oldest version to be discarded. The server supports a variety of requests allowing

  • a new version of a file to be uploaded
  • an existing file version to be downloaded
  • listing of the name and version counts of all files in the cache
  • deletion of all copies of a named file
  • deletion of the whole cache

Continue reading “Dude, where’s my PaaS memory? Tuning Java’s footprint in OpenShift (Part 2)”

Share

Dude, where's my PaaS memory? Tuning Java's footprint in OpenShift (Part 1)

Is Java really greedy for memory?

Java is often blamed for being an over-hungry consumer of physical memory. Indeed, until recently our OpenShift team were tempted to draw this same conclusion. OpenShift is Red Hat’s open source Platform as a Service (PaaS) product. You can access it via public Cloud infrastructure managed by Red Hat (OpenShift Online) or even deploy it to your own data centre/private cloud (OpenShift Enterprise). OpenShift Online provides simple and manageable scalability to anyone developing and deploying web services. One of the OpenShift team’s goals is to maximize the number of guest Java EE deployments on any underlying physical host. However, in the first release of OpenShift meeting this goal was challenged by the high physical memory use observed in many of the deployed JVMs. With only so much memory available on any given physical host the more memory each JVM uses the lower the density of guest deployments.

Continue reading “Dude, where's my PaaS memory? Tuning Java's footprint in OpenShift (Part 1)”

Share