RFR: 8280684: JfrRecorderService failes with guarantee(num_written > 0) when no space left on device.

[David Holmes]

On Wed, 16 Feb 2022 10:17:00 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>> Thank you for your review.  
>> 
>> Whether or not hotspot generate a core file is determined by the argument of vm_abort(bool dump_core).  If the argument is "true", vm_abort(bool dump_core) calls os::abort(bool dump_core) to generate a core file. 
>> See the following code:
>> https://github.com/openjdk/jdk/blob/3c160ab5bec0c2364ec3f43c5a5789098d4699e5/src/hotspot/share/runtime/java.cpp#L625
>> 
>> I think JfrJavaSupport::abort() should pass "false" as an argument to vm_abort(bool dump_core).
>
> Ok. My point was that the os won't be able to create a core file if there is no available space.
> 
> But this is indeed more succinct, if we don't want to create a core categorically from this location.

Just an observation but the filesystem that is full, and the filesystem where a core would be written, need not be the same file system. That said, a core dump in this case seems unwarranted.

>> I use `@run main/manual` in TestJFRDiskFull.java. I think this label means manually test.  
>> I mannually confirmed this test to pass with jtreg after this fix.
>
> My apologies, I missed the @run main/manual decoration. I don't think we have any JFR tests that use it.
> 
> If you can ensure this test is excluded for automatic runs, then perhaps...but then I don't know who will get to run it, so the value of the test is questionable.

Manual tests are excluded if the jtreg test run specifies to run automatic tests only (as we do in our CI). So this really only serves as a validation of the fix, with no real expectation that anyone will necessarily every run it again. Even as a locally run test, filling the disk can easily lead to unexpected problems for other processes - including the swap/paging file on Windows - so this is a risky test to run.

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

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