> But the difference in memory is fundamental. The JVM can now store the values themselves in the array, laid out densely one after another: 8 bytes per point (plus a possible null flag), in a contiguous block. No headers per element. No pointers. No jumping around the heap.

How much was this article proof-read? Didn't they just get finished talking about how heap flattening won't work for objects with > 64-bit representations? Their `Point` is at least 65 bits (two 32-bit ints plus the null flag). The "plus a possible null flag" and oddly short following statements seem to suggest this was some AI that got sidetracked by trying to make emphatic statements... oh and also the "[IMAGE: the same Point[] array in two variants..." block halfway down the page is unfortunate.

> No headers per element. No pointers. No jumping around the heap.

that smells of AI [1], and thus lazy writing. I'm all in for using AI to help you write, but if you don't put your voice to it then there's no reason to read it.

[1] https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing#...

18446744073709551616 possible values and you can't spare 1 for null? :)

TIL that Rust has NonZeroU64 which you can combine with Optional to get the required behaviour with only 64 bits per entry. [1]

[1] https://doc.rust-lang.org/std/num/type.NonZeroU64.html

The obviously used too much AI, I stopped after 2 paragraphs

> This is exactly the moment where non-nullability stops being cosmetics and becomes a lever for performance.

Looks like they just missed the `!`. It should be `Point![]`.

I'm confused about the 2008 Bloomberg article image in the first slot... right after implying the effort started in 2014. With nothing mentioning anything in there.

Is there a way we can request a "flag as AI garbage" downvote for articles? Or should we just flag them?