On Mon, 2 Dec 2024 14:52:38 GMT, Thomas Stuefe <[email protected]> wrote:
>> Hello, @tstuefe , and thanks for your comments. I'll address a few here
>> while I work on the others.
>> I have changed the os-specific names to lowercase, but I don't think it
>> makes them stand out more. The square brackets were intended to do that.
>> Might I change this back?
>>
>> I think there is only one JAVAHEAP segment because due to an issue with my
>> build[1] there was no CDS archive available.
>>
>> I will look at the META and CLASS entries and see if there are hidden
>> properties that I can surface, or if there's another reason for so many
>> entries.
>>
>> [1] I had given a target architecture to the configure command, which turned
>> on cross-compiles (which disables CDS archive building) even when building
>> on the target platform.
>
> Hi @stooke !
>
>> Hello, @tstuefe , and thanks for your comments. I'll address a few here
>> while I work on the others. I have changed the os-specific names to
>> lowercase, but I don't think it makes them stand out more. The square
>> brackets were intended to do that. Might I change this back?
>
> Sure, if it looks worse. I just wanted to make sure we can cleanly
> distinguish NMT sections from OS sections.
>
>>
>> I think there is only one JAVAHEAP segment because due to an issue with my
>> build[1] there was no CDS archive available.
>
> Has nothing to do with CDS. The heap consists of committed and reserved
> areas. Committed areas have backing swap space allocated for them, and are
> accessible. Reserved areas have not and are generally not. API wise the
> difference is that Reserved sections set the MAP_NORESERVE flag for mmap, and
> are generally allocated with PROT_NONE.
>
> So, the heap should show up with several neighboring sections, some
> committed, some just reserved. Similar how most of the stacks should show up
> with two entries, one for the writable stack, one for the guard page that is
> protected.
>
> ---
>
>
> Simple test I did on MacOS with your patch: I reserve 1G of memory at
> startup, uncommitted (added to os::init_2)
>
>
> if (UseNewCode) {
> char* p = os::reserve_memory(G, false, mtInternal);
> tty->print_cr("Pointer is %p", p);
> }
>
>
>
> vmmap shows:
>
>
> VM_ALLOCATE 10ccb4000-14ccb4000 [ 1.0G 0K 0K
> 0K] ---/rwx SM=NUL
>
>
> so, looks good. 1GB, with all protection flags cleared. But System.map shows
> nothing for this address range.
>
>
> Now, I commit the second half of the range:
>
>
>
> if (UseNewCode) {
> char* p = os::reserve_memory(G, false, mtInternal);
> tty->print_cr("Pointer is %p", p);
> bool b = os::commit_memory(p + (512 * M), 512 * M, false);
> assert(b,"???");
> }
>
>
> vmmap shows only the committed part now, omitting the still uncommitted first
> half. But it gets the protection flags right again (rw now):
>
>
> VM_ALLOCATE (reserved) 148000000-168000000 [512.0M 0K 0K
> 0K] rw-/rwx SM=NUL reserved VM address space (unallocated)
>
>
> System.map shows nothing.
>
>
> What goes on? Is the OS lying to us? Do we have an error? Both vmmap and
> System.map seem to struggle, with vmmap being somewhat more correct.
@tstuefe I've look into your test, and I will modify the PR to display these
regions - it was incorrectly identifying them as "free".
As to the strange vmmap behaviour, I found that the two sections appeared in
different places:
the uncommitted spaces appeared in "==== Non-writable regions for process":
`VM_ALLOCATE 300000000-320000000 [512.0M 0K 0K
0K] ---/rwx SM=NUL
`
and the committed spaces in "==== Writable regions for process":
`VM_ALLOCATE (reserved) 320000000-340000000 [512.0M 0K 0K
0K] rw-/rwx SM=NUL reserved VM address space (unallocated)
`
I have made a few changes, track reserved and committed memory better, and
uploaded an updated sample output.
[vm_memory_map_89174.txt](https://github.com/user-attachments/files/18013640/vm_memory_map_89174.txt)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20953#issuecomment-2518444621
