Vast vs constrained address space

[qinsoon]

All the implementation and design up to date is assuming that we are dealing with two types of virtual address space: a vast virtual address space, or a constrained virtual address space.

• For vast virtual address space, we are not concerned that we may use up the virtual address space.
• For constrained virtual address space, it is a real concern that we may use up the virtual address space.

The design trades-off for those two types of virtual address space are different. For one, we could trade the (unlimited) address space for other benefits, like performance, simplicity of implementation, etc. For the other, we may have to do the other way around, trade other benefits to make sure that we do not run out of virtual address space.

The two types of side metadata design (contiguous vs chunked) reflects this. The multiple SFTMap implementations reflects this. The 2TB space extent for vast virtual address space reflects this.

Initially, we have a naive classification that we assumes vast virtual address space for 64 bits programs, and constrained virtual address space for 32bits programs.

This was changed when we introduced support for compressed pointers, which is constrained address space for 64 bits programs (#899). Some platforms also have constrained virtual address space, such as 39 bits address space on 64 bits (#725). For those cases, we use constrained virtual address space solutions for them. We haven't seen a case that shows the current solution for constrained virtual address space is inadequate, and that we need a third solution somewhere between vast and constrained address space.

Memory used by others

In either of the above cases, we have to consider that there will be memory that is unavailable to MMTk. MMTk currently does not handle this well (#1351). But MMTk should handle it, in either vast address space or constrained address space. However, this does not change the assumption that some settings provide vast address space, and we should still take the advantages of that.

[qinsoon]

I think our recent discussions would be clearer if we separate this assumption from the other topics.

[k-sareen]

We haven't seen a case that shows the current solution for constrained virtual address space is inadequate, and that we need a third solution somewhere between vast and constrained address space.

This isn't entirely true since @wenyuzhao has seen virtual address fragmentation for heaps that quite close to hitting the 32 GB compressed pointer limit on OpenJDK.