RFR: 8261029: Code heap page sizes not traced correctly using os::trace_page_sizes

Vladimir Kozlov kvn at openjdk.java.net
Wed Feb 10 17:57:40 UTC 2021


On Wed, 10 Feb 2021 14:45:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> Are you currently working on this? If yes, what are your plans? I have a half finished prototype where I changed os::reserve_xxx() to return meta information about the reservation alongside the pointer, one of them the reserved page size.
>>> 
>> 
>> Yes, I also have a prototype that I've been playing around with. It currently uses an out-parameter to return the page size from `os::reserve_memory_special*` calls. The page sizes is then saved in the ReservedSpace for later use. 
>> 
>>> Have you guys decided whether its okay to remove the "multiple page sizes per reservation" feature?
>>> 
>> 
>> I've done some investigations but nothing have been decided. For now my prototype will return the smallest page size used by a mapping. Going forward I would like to do this, but it feels more urgent to get the other things in place first. 
>> 
>>> There is also another possible simplification I was thinking about, which is to remove the "UseSHM" feature from Linux. I honestly do not know why we still need it. That would simplify rework of large page handling on Linux a lot. I did ask around in December: https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-December/046885.html , but did not get many answers.
>>> 
>> 
>> I know and I've been digging around in this area and agree even more now that it would be great to get rid of `UseSHM`. Not sure how if everybody agrees though and I'm currently working on small fix for `UseSHM` so that at least we don't leave it enabled everytime someone sets `+UseLargePages` without having any explicit large pages enabled ([PR#2488](https://github.com/openjdk/jdk/pull/2488)).
>
>> > Are you currently working on this? If yes, what are your plans? I have a half finished prototype where I changed os::reserve_xxx() to return meta information about the reservation alongside the pointer, one of them the reserved page size.
>> 
>> Yes, I also have a prototype that I've been playing around with. It currently uses an out-parameter to return the page size from `os::reserve_memory_special*` calls. The page sizes is then saved in the ReservedSpace for later use.
> 
> I think that makes sense as a solution for this. My attempt was along this:
> void* os::reserve_xxx(size, ... blabla..., reservation_info_t* info = NULL);
> with reservation_info_t being a holder for information both "public" and opaque: e.g. whether this is executable memory (e.g. for MacOS MAP_JIT issue on committiong), the page size of course, as well as a way for platforms to piggyback internal information (eg. memory type used on AIX).
> 
> But your solution sounds simpler, and its sufficient at least for now. So I don't think we work at cross purposes.
> 
>> 
>> > Have you guys decided whether its okay to remove the "multiple page sizes per reservation" feature?
>> 
>> I've done some investigations but nothing have been decided. For now my prototype will return the smallest page size used by a mapping. Going forward I would like to do this, but it feels more urgent to get the other things in place first.
> 
> No problem, but good to know its not forgotten.
> 
>> 
>> > There is also another possible simplification I was thinking about, which is to remove the "UseSHM" feature from Linux. I honestly do not know why we still need it. That would simplify rework of large page handling on Linux a lot. I did ask around in December: https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-December/046885.html , but did not get many answers.
>> 
>> I know and I've been digging around in this area and agree even more now that it would be great to get rid of `UseSHM`. Not sure how if everybody agrees though and I'm currently working on small fix for `UseSHM` so that at least we don't leave it enabled everytime someone sets `+UseLargePages` without having any explicit large pages enabled ([PR#2488](https://github.com/openjdk/jdk/pull/2488)).
> 
> Nice that you think the same. I am not sure many people are around which know the history. Maybe we should ask Andrew Haley, I believe he wrote some of that coding. 
> 
> I commented on your PR in your PR.
> 
> Cheers, Thomas

> > I agree that alignment here should match one used in CodeCache::reserve_heap_memory() and not recalculated. But I am not sure actual_reserved_page_size() returns correct value.
> > May be we should record value in CodeHeap object when it is created.
> 
> Yes, the `actual_reserved_page_size()` is far from perfect and I plan to update `ReservedSpace` to have a page size member that can be queried in places like this and then we can remove this helper. This will be required once we allow multiple large page sizes ([PR#1153](https://github.com/openjdk/jdk/pull/1153)). That said, `actual_reserved_page_size()` is currently doing a good job returning the correct page size since it is considering both if the space is "special", what alignment it used and if transparent huge pages are enabled.
> 
> I would prefer doing the change that records the page size i `ReservedSpace` as a separate patch and in that patch also remove all uses of `actual_reserved_page_size()`. Doing this change now is required to be able to integrate the [new test](https://github.com/openjdk/jdk/compare/master...kstefanj:test-for-trace-page-sizes) I mentioned, and I think it will be helpful for work in this area going forward.

Are you talking about [8261230](https://bugs.openjdk.java.net/browse/JDK-8261230) to do recording?
Okay, then I am fine with this change.

What testing you did for current changes?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2481


More information about the hotspot-compiler-dev mailing list