RFR: 8256155: 2M large pages for code when LargePageSizeInBytes is set to 1G for heap [v2]
Thomas Stuefe
stuefe at openjdk.java.net
Wed Nov 25 14:02:00 UTC 2020
On Wed, 25 Nov 2020 13:35:18 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:
>> Hi Markus,
>>
>> the more I think about this the more I think it your proposal makes sense.
>>
>> In my opinion I would do it transparently for reserve_memory_special() (so, not tied to code heap).
>>
>> Maybe one way to simplify this and move it forward would be to just do it for UseHugeTLBFS, and leave the UseSHM path unchanged. I consider this less risky since with UseHugeTLBFS we already reserve spaces with mixed page sizes and that seems to work - so here, callers already are wrong if they make any assumptions about the underlying page size. Note that UseHugeTLBFS is the default if +UseLargePages is set.
>>
>> Just my 5 cent.
>>
>> Cheers, Thomas
>
> I agree with what Thomas is saying. This should be a generic thing for reservations, as I've suggested before, choosing the largest page size given the size of the mapping. I would also be good with starting with the `UseHugeTLBFS` case.
>
> When it comes to testing, we should not hard code these kind of things in the test, but add WhiteBox functions that return the correct numbers given the platform and environment.
>
> WhiteBox wb = WhiteBox.getWhiteBox();
> smallPageSize = wb.getVMPageSize();
> smallPageSize = wb.getVMPageSize();
> largePageSize = wb.getVMLargePageSize();
> largePageSize = wb.getVMLargePageSize();
> largePageExecSize = 2097152;
> So instead of hard coding this, I guess the correct approach would be to return an array of available page sizes and verify that the correct one is used.
I honestly don't even know why we have UseSHM. Seems redundant, and since it uses SystemV shared memory which has a different semantics from mmap, it is subtly broken in a number of places (eg https://bugs.openjdk.java.net/browse/JDK-8257040 or https://bugs.openjdk.java.net/browse/JDK-8257041).
-------------
PR: https://git.openjdk.java.net/jdk/pull/1153
More information about the hotspot-dev
mailing list