Question about VirtualSpace and MPSS support

[Thomas Stüfe]

Hi Erik,

On Thu, Nov 17, 2016 at 11:33 AM, Erik Helin <erik.helin at oracle.com> wrote:

> On 11/09/2016 04:00 PM, Thomas Stüfe wrote:
>
>> Hi all,
>>
>
> Hey Thomas, sorry my somewhat late reply.
>
>
no problem, thanks for thinking this thru.


>
> please help me understand some details about the VirtualSpace class.
>>
>> Background: I am experimenting with putting humongous metaspace chunks at
>> the end of the VirtualSpace (part of
>> https://bugs.openjdk.java.net/browse/JDK-8166690). So I would like to
>> have
>> a VirtualSpace which allows me to allocate from both bottom and top.
>> Therefore I am checking how difficult it would be to extend the
>> VirtualSpace class to allow me to grow from both sides.
>>
>> Now I try to understand the three-region-logic implemented to support
>> multiple page sizes:
>>
>> VirtualSpace has three regions with three different granularities. I think
>> the intent is to support large pages for address ranges which are not
>> necessarily large page aligned, so this leaves small-paged regions at top
>> and/or bottom.
>>
>> Looking at VirtualSpace::expand_by() I think the idea is that there is
>> always one continuous committed area spanning those three regions, right?
>> (instead of, say, each of the regions being committed independently). So,
>> just one high water mark, which is either in the low, middle or upper
>> region. If it is in the middle region, low region should be completely
>> committed, if it is in the upper region, low and middle regions should be
>> completely committed? I think it must be this way, because from the
>> outside
>> I only should have one continuous committed address range, otherwise it
>> would be difficult to use this VirtualSpace.
>>
>> But then, I have a function like VirtualSpace::actual_committed_size() -
>> in
>> addition to VirtualSpace::committed_size() - which counts the committed
>> area for all three regions separately. Is there ever a case where comitted
>> size and actual comitted size are different?
>>
>
> Yes, consider the case when you have small pages for the "lower" part of
> the Virtualspace. Due to how paging works in operating systems, you can't
> commit less memory than the size of a small page. So even if a user of a
> VirtualSpace instance wants to expand by a half small page size, the OS
> will still commit a whole small page (the OS can't work on a smaller
> granularity). If that has happened, then commited_size() will return half a
> small page size as its result and actual_commited_size will return one
> small page size as its result. Do you follow?
>
>
Sure! This slipped me. I was assuming VirtualSpace::_high to be always page
aligned, but now I see that this is not the case. Instead, we seem to have
_high, which is the unaligned high water mark the user set with
expand_by(), and then _lower_high, _middle_high, _upper_high, which seem to
be the page-aligned highs for the various regions.

I was expecting the caller to always expand by page size units. But of
course this is wrong because the caller should not have to deal with the
page granularity of the space, especially if it was stitched together from
various page sizes.

Can it be that lower regions are partly comitted even if higher regions are
>> already used?
>>
>
> No, that should never happen (if it does, then that is a bug). The
> following assert should trigger in that case (for fastdebug or debug
> builds):
> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/4d1cc698c0b6
> /src/share/vm/memory/virtualspace.cpp#l734
>
>
How did I miss this :) Thanks for pointing this out!

I wonder why VirtualSpace keeps the unaligned high water mark around
instead of, say, just rounding _high up to the next page boundary. A
simpler approach would have been to advance _high to the next page boundary
and just forget the exact increments the caller requested. Then, caller
needs to deal with the fact that an VirtualSpace may expand by more than
the requested size, and for future size calculations always needs to refer
to VirtualSpace::high(). This could be a cleanup for jdk10.

Thanks, Thomas


> Thanks,
> Erik
>
>
> Thank you!
>>
>> Kind Regards, Thomas
>>
>>