RFR(XS): 8166045: jdk/internal/misc/Unsafe tests fail due to timeout

Christian Tornqvist christian.tornqvist at oracle.com
Mon Sep 26 23:11:37 UTC 2016

Hi Mikael,

This looks good, thanks for fixing this.


> On Sep 26, 2016, at 5:53 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com> wrote:
> Please review the following change:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166045 
> <https://bugs.openjdk.java.net/browse/JDK-8166045>
> Webrev: 
> http://cr.openjdk.java.net/~mikael/webrevs/8166045/webrev.01/jdk/webrev/ 
> <http://cr.openjdk.java.net/~mikael/webrevs/8166045/webrev.01/jdk/webrev/>
> Summary:
> Among the tests I introduced for Unsafe.copyMemory and Unsafe.copySwapMemory 
> a few months ago are a couple of tests which rely on being able to allocate 
> and operate on a large (~2GB) block of native memory. However, on some 
> smallish machines the actual allocation succeeds, but the machine then goes 
> on to swap (as in, page to/from disk) like crazy, making the test time out.
> In an attempt to work around this I’m using @requires in combination with 
> the value of os.maxMemory. I could make the whole test(s) conditional on the 
> memory size, but the vast majority of the test(s) actually operate on a very 
> small block of memory (tens of bytes), so disabling the whole test seems 
> unfortunate. Instead I decided to split up the test(s) in two - one set 
> which tests the default/small size, and one set which tests the large size 
> iff there is enough memory on the machine.
> I have tested manually that the @requires check has the right effect - the 
> tests are skipped if there’s not enough memory on the machine - and that the 
> tests still pass as expected.
> I also took the liberty of removing a superfluous import.
> Cheers,
> Mikael

More information about the hotspot-dev mailing list