RFR(S): 8223396: [TESTBUG] several jfr tests do not clean up files created in /tmp

[mikhailo.seledtsov at oracle.com]

Hi David,

On 6/3/19 12:10 AM, David Holmes wrote:
> Hi Misha,
>
> On 1/06/2019 6:47 am, mikhailo.seledtsov at oracle.com wrote:
>> Please review this change that converts all uses of 
>> Files.createTempFile/createTempDirecotry in JFR tests to
>> use corresponding test library Utils methods. Using test.lib.Utils 
>> for this purpose is a recommended practice
>> for JDK tests.
>>
>> I have also create a new method in jdk.test.lib.Utils: 
>> createTempDirectory()
>>
>>      JBS: https://bugs.openjdk.java.net/browse/JDK-8223396
>>      Webrev: http://cr.openjdk.java.net/~mseledtsov/8223396.00/
>>      Testing:
>>          1. Locally: ran the affected tests (Mac) - All PASS
>>          2. test cluster: running jdk_jfr and tier1 - in Progress
>>
>> Note: to be safe, I will not integrate this until Monday morning.
>
> This all seems like good practice.
>
> My only query is that you no longer mark the temporary files as 
> delete-on-exit. That may be useful incase the test fails, but do you 
> know how big these temporary files may be? If they are massive then 
> they may cause failures/timeouts when the testing infrastructure tries 
> to bundle them up.

Good point.

I ran the tests 5 times with -retain:all, and checked the sizes of 
artifacts left behind. They are similar to this one run:

    80778 Jun  3 18:31 
./jdk/jfr/event/io/TestDisabledEvents/recording-1-pid2705.jfr
    83403 Jun  3 18:31 
./jdk/jfr/event/io/TestFileChannelEvents/recording-1-pid2707.jfr
    82420 Jun  3 18:31 
./jdk/jfr/event/io/TestFileReadOnly/recording-1-pid2709.jfr
    83232 Jun  3 18:31 
./jdk/jfr/event/io/TestFileStreamEvents/recording-1-pid2711.jfr
    83377 Jun  3 18:31 
./jdk/jfr/event/io/TestRandomAccessFileEvents/recording-1-pid2714.jfr
   115651 Jun  3 18:31 
./jdk/jfr/event/io/TestRandomAccessFileThread/recording-1-pid2716.jfr
   352286 Jun  3 18:32 
./jdk/jfr/jvm/TestJavaEvent/test12858226465185116105.jfr

Most of them are under 100k, and the largest is slightly over 300k. I 
think these are reasonable sizes, given the fact that these files are 
only retained when failure occurs.

I hope this alleviates your concerns about very large size of artifacts.


Thank you,
Misha



>
> Thanks,
> David
>
>>
>> Thank you,
>> Misha
>>