Space virtual address management (discontiguous spaces)

I am not sure if I understand the implications of the proposed design (then again it could be my cold befuddled mind!).

For discontiguous spaces, will it be possible for one space to expand and contract based on usage patterns. Restricting a space to a fixed address range would seem to limit this unless all spaces except the nursery cover the entire memory space (except the nursery address range and any library addresses).

Another concern is how pinned objects will interact with non-pinned objects (if/when the RVM ever supports the pinning). Will pinned objects be managed by a separate space? Will the series of chunks (is the correct term Segment?) they are allocated in simply be holes that the virtual address manager deals with specially while they are live.

For discontiguous spaces, will it be possible for one space to expand and contract based on usage patterns.

Not sure what you mean.

There are two concepts of "size" w.r.t. spaces. a) the number of pages actually in use at any time, and b) the address space associated with the space.

In both contiguous spaces and discontiguous spaces, a) is a dynamic property (it can and does expand and contract) and b) is a static property. The difference is that for a discontiguous spaces, b) is shared with other discontiguous spaces sharing the same address range.

Restricting a space to a fixed address range would seem to limit this unless all spaces except the nursery cover the entire memory space (except the nursery address range and any library addresses).

Perhaps my previous answer helped. There's nothing necessarily special about the nursery---it was just an example I gave which may have some restrictions (and would for our current generational collectors). In any case, reducing the number of fixed address ranges obviously increases flexibility. So if most discontiguous spaces shared one address range that would give most opportunity for dynamic load balancing of address space use.

Another concern is how pinned objects will interact with non-pinned objects (if/when the RVM ever supports the pinning). Will pinned objects be managed by a separate space? Will the series of chunks (is the correct term Segment?) they are allocated in simply be holes that the virtual address manager deals with specially while they are live.

Hmmm... I don't see the connection between pinning and this issue. We want to support pinning (I'm tinkering with it right now). Exactly how you do it depends a great deal on a) the pinning semantics we want to support (and there are many), and b) the GC policies we want to use to support it, but is (as far as I can see) entirely independent of whether the containing space is contiguous or discontiguous.

Ignore comment about pinning - I am not sure what I was babbling about.

The design works for wrt to virtual address management.

I guess we will need to address the introduction of many more build time configuration parameters as I can easily imagine the scenario where;

• we want to stay with existing arrangement
• want most flexibility in managing memory allocation and thus almost all spaces but the nursery become overlapping
• on 64 bit architectures where virtual address ranges are "cheap" make all spaces non overlapping

This patch is a first cut at adding discontiguous spaces.

Conspicuously missing are changes to FreeListPageResource to allow it to deal with discontiguous spaces. So only CopySpace and ImmortalSpace use discontiguous spaces for the moment. So SemiSpace uses discontiguous spaces, for example.

To my surprise, initial performance testing showed a consistent small (0.5%) advantage on FastAdaptiveSemiSpace. I don't yet understand this.

I have finished a first cut at discontiguous spaces. With this, we now only use contiguous spaces for the nursery---all other myriad spaces are interleaved in virtual memory now (immortal, raw pages, LOS, mature space, etc).

This patch (against 13397) has a number of obvious shortcomings:

1. It is not extensively tested
2. It is very inefficient in generation page allocation maps for each discontiguous FreeListPageResource (it creates a map for each instance which covers the entire possible space, which is grossly redundant).

I've run some perf regressions on DaCapo and seen that it is robust in that setting and actually performs quite well, with the notable exception of a regression on jython whereby we do 30% extra GCs. This is presumably due to a bug in my approach.

I discussed 2. above with Robin and Daniel. Daniel has previously proposed injecting another layer of abstraction to the design of spaces etc, whereby virtual memory segmentation is shifted to a high level of abstraction. Virtual memory is carved up into vm regions and then spaces are associated with these, either contiguously or discontiguously, but nonetheless, constrained to a single vm region. This seems like a good approach, adn I think we should attack it in the short to medium term. Therefore I think the inefficiency in 2. above is fine because that whole issue would be treated entirely differently under the new arrangement. I prefer not to invest time polishing up a perfect solution to 2 if we know the premise is bad and that a better approach is in our sights.

Anyway, I'll try to get back to this soon, but the patch is here so if any one is chaffing at the bit to do this and doesn't want to wait for me, they can at least take a look at a first cut solution....

This patch still needs some cleaning up and straightening out, but I think it's fairly close to being ready to commit.

Unfortunately I've timed out for today.

Closed in r13626