Operating System

Behavior is easy, state is hard: Tame inconsistent state in your Java code

Behavior is easy, state is hard: Tame inconsistent state in your Java code

yanagaburrsutter
By Edson Yanaga and Burr Sutter

DevNation Tech Talks are hosted by the Red Hat technologists who create our products. These sessions include real solutions plus code and sample projects to help you get started. In this talk, you’ll learn the root cause of common inconsistent state-related bugs in your production Java code—and how to solve them—from Edson Yanaga and Burr Sutter.

Continue reading Behavior is easy, state is hard: Tame inconsistent state in your Java code

Share
Improve your code: Tales from confinement without a debugger

Improve your code: Tales from confinement without a debugger

aldyh
By Aldy Hernandez

I have always been impressed by developers who make do without a debugger, and have often wished I could be more like them. I vaguely recall a colleague saying he never used a debugger, favoring printf over gdb. Also, in my rookie years, I vividly recall chasing a kernel bug with a friend who was using objdump and the source of a much older kernel:

“Richard, shouldn’t you at least use the correct source?”
“Meh … they’re close enough.”

I’m still impressed.

Now that I have coded for some years, I’ve noticed that I have picked up some bad habits along the way. Over-dependence on the debugger is one of them. I often use it as a high-powered crutch, which frequently leads me waist-deep into stack traces, rarely stopping to think things through. I get lost inside 20 levels of recursion and wonder why an irrelevant variable is being tickled.

Granted, there are many good uses for a debugger, but I’m at 40% on the good use scale. My uses usually start benign but then degrade into cancerous abstractions. So, for my 20th GNU Compiler Collection (GCC) hacking anniversary, I decided to give myself the challenge of one month without a debugger. Here is the tale.

Continue reading “Improve your code: Tales from confinement without a debugger”

Share
Profile-guided optimization in Clang: Dealing with modified sources

Profile-guided optimization in Clang: Dealing with modified sources

sguelton
By Serge Guelton

Profile-guided optimization (PGO) is a now-common compiler technique for improving the compilation process. In PGO (sometimes pronounced “pogo”), an administrator uses the first version of the binary to collect a profile, through instrumentation or sampling, then uses that information to guide the compilation process.

Profile-guided optimization can help developers make better decisions, for instance, concerning inlining or block ordering. In some cases, it can also lead to using obsolete profile information to guide compilation. For reasons that I will explain, this feature can benefit large projects. It also puts the burden on the compiler implementation to detect and handle inconsistencies.

This article focuses on how the Clang compiler implements PGO, and specifically, how it instruments binaries. We will look at what happens when Clang instruments source code during the compilation step to collect profile information during execution. Then, I’ll introduce a real-world bug that demonstrates the pitfalls of the current approach to PGO.

Continue reading “Profile-guided optimization in Clang: Dealing with modified sources”

Share
Introducing the Red Hat build of the OpenJDK Universal Base Images—now in Red Hat Enterprise Linux 8.2

Introducing the Red Hat build of the OpenJDK Universal Base Images—now in Red Hat Enterprise Linux 8.2

chateaguilarjdowland
By Ezequiel Aguilar and Jonathan Dowland

With the recent release of Red Hat Enterprise Linux 8.2, we also added the first Red Hat build of OpenJDK Universal Base Images. These General Availability (GA) images for OpenJDK 8 and OpenJDK 11 set a new baseline for anyone who wants to develop Java applications that run inside containers in a secure, stable, and tested manner.

In this article, we introduce the new OpenJDK Universal Base Images and explain their benefits for Java developers. Before we do that, let’s quickly review what we know about UBIs in general.

About Universal Base Images

Red Hat Universal Base Images (UBIs) are:

OCI-compliant container base operating system images with complementary runtime languages and packages that are freely redistributable. Like previous base images, they are built from portions of Red Hat Enterprise Linux (RHEL). UBI images can be obtained from the Red Hat container catalog and be built and deployed anywhere.

In other words, UBIs help application developers reach the secure, stable, and portable world of containers. These images are accessible using well-known tools like Podman/Buildah and Docker. Red Hat Universal Base Images also allow users to build and distribute their own applications on top of enterprise-quality bits that are supportable on Red Hat OpenShift and Red Hat Enterprise Linux.

Continue reading “Introducing the Red Hat build of the OpenJDK Universal Base Images—now in Red Hat Enterprise Linux 8.2”

Share
Debugging GraalVM-native images using gdb

Debugging GraalVM-native images using gdb

andrewdinn
By Andrew Dinn

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
Mandrel: A community distribution of GraalVM for the Red Hat build of Quarkus

Mandrel: A community distribution of GraalVM for the Red Hat build of Quarkus

nmcl2001
By Mark Little

The Java community has demonstrated time and time again its ability to evolve, improve, and adapt to meet the needs of its developers and users. Even after 25 years of language and framework choices, Java has consistently ranked in the top languages in use today due to its strong track record and capabilities in enterprise use cases. Red Hat has long been a strong leader in Java and open source software development and remains committed to being at the forefront of Java as it continues to evolve.

Today, Red Hat and the GraalVM community jointly established a new downstream distribution of GraalVM, called Mandrel. This distribution will power the Red Hat build of Quarkus, a recently announced addition to Red Hat Runtimes. This article explains what Mandrel is and why it is necessary.

Continue reading “Mandrel: A community distribution of GraalVM for the Red Hat build of Quarkus”

Share
The joys and perils of aliasing in C and C++, Part 2

The joys and perils of aliasing in C and C++, Part 2

msebor
By Martin Sebor

In the previous article, I discussed the benefits of C and C++ language restrictions in optimized code. In this second half, I present a variety of programming language exemptions and compiler extensions that developers can use to get around aliasing restrictions more or less safely. I will also discuss the common pitfalls of aliasing, both resulting from the extensions as well as from misuses of standard language constructs, and illustrate common problems these pitfalls might cause.

Continue reading “The joys and perils of aliasing in C and C++, Part 2”

Share
The joys and perils of C and C++ aliasing, Part 1

The joys and perils of C and C++ aliasing, Part 1

msebor
By Martin Sebor

In C, C++, and some other programming languages, the term aliasing refers to a situation where two different expressions or symbols refer to the same object. When references access that object in different ways—as both reads and stores—there are consequences for the order in which these mixed accesses can happen. The value that is stored first is expected to be read by the subsequent access. In many instances, aliasing is harmless: It is common, safe, and usually optimally efficient to use two pointers of the same type to read, and even to write to the same object. But in some cases, using aliasing symbols for mixed accesses is less benign, and can adversely affect the correctness or efficiency of your code.

Although there are quite a few articles on this subject, most tend to focus on the rules and requirements outlined in the standards (such as the strict aliasing rule). In this article, I focus on the details of the C and C++ language restrictions, their challenges and pitfalls, and examples demonstrating the restrictions’ beneficial effects in optimized code. In Part 2, I will present exemptions from aliasing, which can help you get around the restrictions more or less safely. I also consider some of the common pitfalls of aliasing and mixed accesses, and the actual problems these pitfalls might cause.

Continue reading “The joys and perils of C and C++ aliasing, Part 1”

Share