RFR: 8323807: Async UL: Add a stalling mode to async UL [v19]
Johan Sjölen
jsjolen at openjdk.org
Mon Feb 24 13:30:54 UTC 2025
On Wed, 18 Dec 2024 10:45:48 GMT, David Holmes <dholmes at openjdk.org> wrote:
>>> > I was considering whether we should vm_exit_out_of_memory if that occurs.
>>>
>>> I prefer not to have secondary functionality, like logging, abort the VM. If malloc fails no doubt we will soon have an issue in primary functionality, but we will deal with that then.
>>
>> Sounds like you think the preferred way to go is to just ignore the stalled message on OOM and continue on until something else in the system fails? Fine by me.
>>
>>> > Is there something in particular you had in mind?
>>>
>>> Just running some small app with e.g. -Xlog:all=trace and checking that the different modes seem to cope okay with what they encounter.
>>
>> I believe that that is what I did with my Spring Boot experiment :-).
>
>> I believe that that is what I did with my Spring Boot experiment :-).
>
> Right. Sorry I see my comment could have been misconstrued. I wasn't referring about additional testing for this PR, but adding additional UL-async-stall testing in our regular tier testing somewhere.
@dholmes-ora , @xmas92 ,
Hi. I've merged with mainline and run the tests locally and did some self-review. I applied Axel's suggestion to use `_data_available` as one signal for both states. Does this look good to you? Assuming GHA (and any other tests) passes, of course.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/22770#issuecomment-2678418484
More information about the hotspot-runtime-dev
mailing list