On Thu, 5 Dec 2024 17:41:00 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
>>> @tstuefe I ran an experiment with raw mmap, and there's no way to >>> differentiate between one large allocation of 5*128MB and 5 smaller >>> allocations of 128MB. I _could_ add code to fold these, but we risk loosing >>> information. >> >> What information would we loose? >> >> As it is now, the display is somewhat confusing. We did not allocate the >> heap with multiple mmap calls, each one of 128MB in size; we use a single >> mmap call. >> >> If you want to close the work for now and leave this glitch for later, we >> can do this too. > >> @tstuefe if it's up to me, I would leave the folding for a quick later PR >> (in fact I would start it right after this one goes in). I also would like >> to investigate the use of mach_make_memory_entry_64() which could be >> interesting on it's own. >> >> Do you know how I can get the GitHub runner to start working? It seems one >> of them is misconfigured. > > No idea, but it was broken for a while now, wasn't it? If you figure it out > and fix it a lot of ppl would be thankful :) > > Otherwise, since the code does not touch anything dangerous, I think its fine > to check it in as long as the other platforms are green and you have executed > the relevant test on MacOS for System.map and System.dump_map @tstuefe , I've actually added the combining code here, and reconfirmed that both the System.map and System.dump_map tests pass on my arm M2. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20953#issuecomment-2521151800
