Hi David,
On 8/5/20 9:03 PM, David Holmes wrote:
Hi Chris,
On 6/08/2020 11:16 am, Chris Plummer wrote:
Hello,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8251121
http://cr.openjdk.java.net/~cjplummer/8251121/webrev.00/index.html
On OSX (and possibly some linux systems), core files are not produced
in the cwd, but instead end up in some well known location. For OSX
it is the /cores directory. The core files tend to accumulate there.
This fixes the core file accumulation problem by moving the core file
into the cwd, allowing jtreg to manage it. By default jtreg will
delete the core if the test passes, and retain if if the test fails
or RETAIN=all is specified.
So the current code returns the absolute path to the corefile, while
your new code just returns the corefile name - which is effectively
the relative path ./corefilename. Is that change going to cause a
problem for any clients of this API?
No. They just want the path to the core file, wherever it is. It can be
a relative or absolute path.
Second we have theorised about the length of time it can take to dump
the corefile on macOS, and now we are moving that huge corefile to
another location, likely on a different disk. Could that make the
timeout problem worse?
Possibly, but I wouldn't think by much. We actually don't have an
explanation as to why it takes so long. It's more like the OS is getting
wedged for a while rather than it just having to do a lot of processing
and I/O. (I'm seeing the spinning beach ball in the back of my head
right now). Compared to the 30 minutes we are currently allowing for the
core dump, I would hope a 3-5g disk to disk copy would not take that
long relatively speaking.
thanks,
Chris
Thanks,
David
-----
I got rid of the code in ClhsdbCDSCore.java that explicitly deletes
the core file because we don't want it deleted if RETAIN=all is used.
thanks,
Chris
