As humans, this can be a rather simple task: we apply the formulas we know to convert one expression to another. But for computers, they may not be aware of all the general nuances and complexities that come with math expressions. Therefore, many checkers typically choose the brute force approach: that is, plug in numbers and check whether the returned values are the same. Rather simplistic, but it gets the job done well in a number of cases.

Let's take a look at an example:

Take a moment to convince yourself that $f_1(x)=f_2(x)$ due to the Power of a Quotient rule. Therefore if we were to create a new equation:

We should see that $d(x)=0$ for all values of $x$. So, when we look at a graph:

...hm, well that's weird. The graph seems to stop arbitrarily at $x=1024$ while increasing exponentially around $x=-80$. And what's with that giant black bar at $x=-680$ to $x=-650$?

Well, my dear readers, welcome to the wonderful world of floating point precision errors.

Hmm? What's a floating point precision error, you ask? Well, let me show you through a simple example.

Evaluate:

Did you think the answer is $0.3$? Well, I'm sorry to tell you that you're wrong. It's actually $0.30000000000000004$. Don't believe me? Open up a JavaScript console and try it yourself.

To understand why, let's look at the binary representations of these numbers. JavaScript stores decimal values as double-precision floating-point numbers following the IEEE 754 standard. This means that a float is made up of 8 bytes, or 64 bits.

The IEEE 754 standard stores floating point numbers as a sort-of scientific notation with three parts: a 1 bit sign (positive or negative), a 52 bit fraction or significand, and a 11 bit exponent all in base 2.

We can get the bytes of a number with a neat little coding trick:

function floatToBinaryString(value) {
    var output = '';
    // Get the bytes in reverse order
    for (const part of new Uint8Array(new Float64Array([value]).buffer, 0, 8)) {
        // Convert to string
        var partString = (part >>> 0).toString(2);
        // Pad any missing zeros
        while (partString.length < 8) partString = '0' + partString;
        // Prefix to place in proper order
        output = partString + output;
    }
    return output;
}

Using this, the binary representations of our two numbers are:

// Values are displayed in the correct order
// In the form '<Sign> <Exponent> <Fraction>'
0.1 = 0 01111111011 1001100110011001100110011001100110011001100110011010
0.2 = 0 01111111100 1001100110011001100110011001100110011001100110011010

Now at a glance, you can tell something is weird, especially with that fraction part. It shouldn't be that complicated to store $0.1$ or $0.2$ in base 2, right?

Why don't we try evaluating these binary values manually then?

The sign is rather straight forward (0 if positive and 1 if negative). The same goes for the fraction: the sum of all $2^{-n}$ that have a 1, where $n$ is the bit number starting from 1, plus 1. The exponent, on the other hand, is calculated differently to allow for negative values. This is done by performing the standard base 2 to base 10 conversion, then subtracting $2^{k-1}-1$, where $k$ is the number of bits in the exponent (in this case $k=11$). Then all of these parts are multiplied together.

That was probably not explained that well, so let me show you the code:

// Outputs the sign
function binaryStringToSign(value) {
    // Gets the sign value from the first part
    return value[0] === '0' ? 1 : -1;
}

// Outputs the 2^n exponent
function binaryStringToExponent(value) {
    var output = 0;
    // Compute initial exponent
    for (var i = 0; i < 11; i++) {
        const bit = parseInt(value[i + 1]);
        output += bit * 2 ** (11 - 1 - i);
    }
    // Apply bias
    output -= (2 ** (11 - 1)) - 1;
    // Return exponent to raise '2' to
    return output;
}

// Outputs the 2^n exponents to sum together and add 1
function binaryStringToFractionParts(value) {
    const output = [];
    // Compute fraction parts
    for (var i = 0; i < 52; i++) {
        const bit = parseInt(value[i + 12]);
        if (bit === 1) output.push((-(i + 1)));
    }
    return output;
}

With all this, we can add up the values in our accurate calculator of choice (e.g., Wolfram Alpha):

Well, that's pretty much $0.1$ and $0.2$, but it's not exactly those values. It's just a really accurate approximation, leaving some room for precision error.

But wait. Adding those two numbers together, we get:

Which is definitely not $0.30000000000000004$. Though, surprisingly enough, if we put that number into the JavaScript console, it does equal that value. So, there's even more precision bugs to work out.

Adding two floating-point numbers together require the exponents to be the same before adding the fraction component. First, let's convert this to a more convenient form to perform the operations on:

In this case, the exponent for $0.1$ is $01111111011$ while it's $01111111100$ for $0.2$. Well, that's easy enough to deal with. We can increase the exponent for $0.1$ by 1 by shifting the fraction component 1 to the left.

Now all that's left to do is add the two fraction parts together:

Which we can rewrite as:

Shift to match proper scientific notation:

And round since there are now 53 bits representing the exponent. We round up if the 52nd bit is 1, and down if 0:

Which leaves us with the final number:

0.3 = 0 01111111101 0011001100110011001100110011001100110011001100110100

And sure enough, evaluating the floating-point precisely gives us:

Where we can now see that pesky $4*10^{-17}$ rounding error. It's all a game of approximation math. And with those precision issues, $(\frac23)^{x}-(\frac{2^x}{3^x})\neq0$.

However, that graph hold a lot more math limitations than you think. But that's a story for next week.

I was the one responsible for implementing the mitigation strategy and writing the blog post for the NeoForged team. It was quite fun to research and learn some new things during the process.

However, this blog post has nothing to do with that.

During the review phase of the post, the original reporter of the exploit Paul mentioned that trying to allocate an array with Integer.MAX_VALUE will likely fail before any memory is allocated. This actually comes from a comment in ArraysSupport that states:

// From `ArraysSupport`
/**
 * A soft maximum array length imposed by array growth computations.
 * Some JVMs (such as HotSpot) have an implementation limit that will cause
 *
 *     OutOfMemoryError("Requested array size exceeds VM limit")
 *
 * to be thrown if a request is made to allocate an array of some length near
 * Integer.MAX_VALUE, even if there is sufficient heap available. The actual
 * limit might depend on some JVM implementation-specific characteristics such
 * as the object header size. The soft maximum value is chosen conservatively so
 * as to be smaller than any implementation limit that is likely to be encountered.
 */
public static final int SOFT_MAX_ARRAY_LENGTH = Integer.MAX_VALUE - 8;

To which I thought... really? So I gave it a quick try with Microsoft's OpenJDK using new Object[Integer.MAX_VALUE], and lo and behold:

Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit

It did throw the error. And trying with new Object[Integer.MAX_VALUE - 8] created the array successfully, at the cost of ~8GiBs of heap usage.

I could've left it there with a 'neat' and moved on, but the 'some JVMs' part kept rattling around in my head. Since it's 'some', wouldn't that mean there exists a JVM that allows new Object[Integer.MAX_VALUE]? Actually, what is the maximum number of elements an array can hold?

So, I decided to test it.

Using SDKMAN!, I downloaded the latest release of every JVM, including the JetBrains Runtime (JBR) separately, into a Debian 13 container and ran a quick little allocation test using:

public class AllocationTest {

    public static void main(String[] args) {
        // Start with max size
        int size = Integer.MAX_VALUE;
        while (true) {
            try {
                Object[] maxCapacity = new Object[size];
                // Break after successful allocation
                break;
            } catch (OutOfMemoryError error) {
                // Too large, reduce size
                size--;
            }
        }
        System.out.println("Max Size: " + size);
    }
}

Nothing to complex, it attempts to construct an array with the given size, and if an OOM is thrown, it repeats the process with one number smaller until does. With 18GiBs to play around with, I got the following results:

Strangely, only IBM's Semeru JVM allowed the array to allocate an Integer.MAX_VALUE of elements. Even stranger, the other JVMs allocated Integer.MAX_VALUE - 2, which is six greater than the ArraysSupport.SOFT_MAX_ARRAY_LENGTH.

So, for the first part, that's because of the underlying base making up the JVMs. Every single one except for IBM's Semeru is based off of HotSpot, where that comment comes from. Meanwhile, Semeru is based on OpenJ9, which provides a different implementation of the JVM spec. We can see that even more clearly when trying to go outside the maximum bounds of an ArrayList via add.

For HotSpot JVMs:

Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit
        at java.base/java.util.Arrays.copyOf(Arrays.java:3509)
        at java.base/java.util.Arrays.copyOf(Arrays.java:3478)
        at java.base/java.util.ArrayList.grow(ArrayList.java:238)
        at java.base/java.util.ArrayList.grow(ArrayList.java:245)
        at java.base/java.util.ArrayList.add(ArrayList.java:484)
        at java.base/java.util.ArrayList.add(ArrayList.java:497)

And for Semeru's OpenJ9 JVM:

Exception in thread "main" java.lang.OutOfMemoryError: Required array length 2147483647 + 1 is too large
        at java.base/jdk.internal.util.ArraysSupport.hugeLength(ArraysSupport.java:914)
        at java.base/jdk.internal.util.ArraysSupport.newLength(ArraysSupport.java:907)
        at java.base/java.util.ArrayList.grow(ArrayList.java:235)
        at java.base/java.util.ArrayList.grow(ArrayList.java:245)
        at java.base/java.util.ArrayList.add(ArrayList.java:484)
        at java.base/java.util.ArrayList.add(ArrayList.java:497)

Same OOM, but different reasoning. Though, the OpenJ9 error doesn't make much sense since it implies it would let you create a larger array if it wasn't limited to a signed integer.

As for why they allow allocation up to those values, I have no idea. After asking around, someone mentioned that the Java Virtual Machine Specification (JVMS) defines that the first two entries could be taken up by the array's length followed by its data type, but I was unable to find such a explanation within the doc. Most likely, it's just up to the JVM to choose how arrays are implemented. After all, "the soft maximum value is chosen conservatively so as to be smaller than any implementation limit that is likely to be encountered." (From ArraysSupport.SOFT_MAX_ARRAY_LENGTH)

Now, of course there are other JVMs other than the two big ones everyone forks, so what about those? Well, the problem is that most of those JVMs are implemented for pre-8 versions, which fails spectacularly in modern containers with modern libraries. To actually get it working in a container, I'd have to build an old linux distro from scratch, install the dependencies from some archival site, and then just hope there isn't any weird implementations preventing me from building it from source. So I thought about it...

...and moved on.

What? That's way too much effort for "how big can I make my array" when the likelihood of me actually ever reaching that limit is slim to none. I'd much rather go down some different rabbit holes.

So all in all, the main difference between the array implementations is that I can store two more elements in Semeru than the others.

...yeah, definitely an interesting use of my time.