The memory mapping trick they use on x86 to avoid masking only works up to the maximum 48 bits of addressable virtual memory, so there is much less than 22 free bits in that case.
It's also not quite free since it takes up TLB space.
It's also not quite free since it takes up TLB space.
In practice, I would wager the performance concerns aren't huge, but that's mostly just a guess. I'd personally be interested in seeing a comparison to masking to see just how much slower masking would be, but obviously it's not like they can just flip a switch to use masking.
It doesn't. The article mentions it's only 3 mappings since those bits are colors, not arbitrary combinations of flags.
> I don't know how Java does it's memory management but if it does lots of small mappings (Which I'm guessing it does not) then that could be a concern.
openjdk generally uses large contiguous mappings but it may punch holes in the middle of the heap if it's configured to yield back memory to the OS. But applications that dynamically shrink and expand their heaps are not necessarily those that are concerned about the last quantum of page table overhead.
> And like you mentioned with the TLB
On the other hand it does support huge pages to mitigate costs of TLB entries.
Nope. They went into this in the article:
> Since by design only one of remap, mark0 and mark1 can be 1 at any point in time, it’s possible to do this with three mappings. There’s a nice diagram[1] in the ZGC source for this.
[1]: http://hg.openjdk.java.net/zgc/zgc/file/59c07aef65ac/src/hot...
That might not be totally current, as it doesn't cover the finalizable flag, but if it works the same, that would only be four mappings. If it works differently, then it would be a maximum of 6 mappings. Not 16.
In other words, just because the alternate mappings exist doesn't mean the pointers always have values that actually use them.