RFR: JDK-8213214: Set -Djava.io.tmpdir= when running tests

[Jonathan Gibbons]

On 6/17/20 5:55 AM, Erik Joelsson wrote:
> On 2020-06-16 15:53, Jonathan Gibbons wrote:
>> It would also be good to identify the tests that are using temporary 
>> directories in this manner and have them use the jtreg scratch 
>> directory where possible.
>>
> I completely agree that tests should be fixed to behave better. Using 
> scratch instead of tmp is (almost) always a much better idea.
>
> This workaround is needed to solve the immediate problem of certain 
> classes of machines in our test farm filling up small disks very fast.

Maybe some part of the system (i.e. either Makefile or jtreg) could 
generate a list after the test run of what (new) files were written into 
java.io.tmpdir.

-- Jon


>
> /Erik
>
>> -- Jon
>>
>> On 6/16/20 12:22 PM, Erik Joelsson wrote:
>>> (re-sending this as it doesn't look like it was delivered)
>>>
>>> There are a lot of jtreg tests that use temporary files. These 
>>> temporary files add up over time and fill up the global temp 
>>> directories on our test systems. To tackle this, we should try to 
>>> redirect these temporary files into a directory controlled by the 
>>> test framework. Jtreg does not do this, but we can set 
>>> -Djava.io.tmpdir from RunTest.gmk. This will not prevent all temp 
>>> files from being created outside of the work dir, but at least most.
>>>
>>>
>>> I have found one test where this becomes an issue, 
>>> java/nio/file/Path/Misc.java on Windows when running in elevated 
>>> mode with the workspace on a subst drive. This looks like an actual 
>>> issue in the product, so I have filed a separate bug for it [1]. 
>>> Since we currently use subst in our distributed test system to get 
>>> around Windows path length issues, we are hitting this problem. 
>>> While the bug is being evaluated, I have implemented a workaround in 
>>> the test so that it is able to handle the known situation. I would 
>>> like to have someone from core-libs look at the workaround.
>>>
>>> Webrev: http://cr.openjdk.java.net/~erikj/8213214/webrev.01/
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213214
>>>
>>> /Erik
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8213216
>>>
>>>