[crac] RFR: Persist memory in-JVM

[Anton Kozlov]

On Mon, 4 Sep 2023 06:15:37 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/hotspot/os/linux/crac_linux.cpp line 578:
>> 
>>> 576:   while (persist_futex) {
>>> 577:     syscall(SYS_futex, &persist_futex, FUTEX_WAIT_PRIVATE, 1, nullptr, nullptr, 0);
>>> 578:   }
>> 
>> I'm not sure will this guarantee no stack accesses. I met with compiler just spilling valued to x86-64 red zone below SP https://en.wikipedia.org/wiki/Red_zone_(computing).
>> 
>> To avoid dealing with this problems, does it make sense to leave a page or two around SP still mmapped?
>
> You're right, it is not a sufficient guarantee (though in practice it works well enough for the POC) - I've checked assembly and found that there were some accesses (though this is not related to red zone IMO). Ideally I would rewrite this into assembly (which is not too difficult but requires arch-specific code) - it's kind of guesswork to estimate how far the access could go.

So, does it make sense to leave a few top pages still mapped to avoid the problem?

>> src/hotspot/share/runtime/crac.cpp line 361:
>> 
>>> 359:   MonitorLocker ml(PeriodicTask_lock, Mutex::_safepoint_check_flag);
>>> 360:   WatcherThread::watcher_thread()->unpark();
>>> 361: }
>> 
>> This looks like a part of #106
>
> Yes, this PR includes those commits so that it can actually run. I wonder why Github still highlights those now that #106 is integrated, and there shouldn't be any diff. I can rebase...

I think it will be enough to make any update (an empty commit probably would work), but it would be cleaner to just merge the target branch into your dev branch.

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

PR Review Comment: https://git.openjdk.org/crac/pull/95#discussion_r1315120282
PR Review Comment: https://git.openjdk.org/crac/pull/95#discussion_r1315119954