The LargeJarEntry test tests that large jar files can be signed without running
OutOfMemory (see 6405538). It runs with the java -Xmx8M flag so that it can hit the bug
more easily by constraining the memory available to the JVM.

The test was failing with an OutOfMemory error on a Windows platform with the
following stack trace:

java.lang.Exception: Test failed with OutOfMemoryError
	at LargeJarEntry.main(LargeJarEntry.java:52)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:83)
	at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.OutOfMemoryError: Java heap space
	at java.io.WinNTFileSystem.list(Native Method)
	at java.io.File.list(File.java:973)
	at sun.security.provider.SeedGenerator$1.run(SeedGenerator.java:166)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.security.provider.SeedGenerator.getSystemEntropy(SeedGenerator.java:146)
	at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:170)
	at java.security.SecureRandom.nextBytes(SecureRandom.java:433)
	at java.security.SecureRandom.next(SecureRandom.java:455)
	at java.util.Random.nextInt(Random.java:189)
	at sun.security.provider.DSA.generateK(DSA.java:409)
	at sun.security.provider.DSA.engineSign(DSA.java:251)
	at java.security.Signature$Delegate.engineSign(Signature.java:1128)
	at java.security.Signature.sign(Signature.java:522)
	at sun.security.tools.SignatureFile$Block.<init>(JarSigner.java:1902)
	at sun.security.tools.SignatureFile.generateBlock(JarSigner.java:1822)
	at sun.security.tools.JarSigner.signJar(JarSigner.java:990)
	at sun.security.tools.JarSigner.run(JarSigner.java:203)
	at sun.security.tools.JarSigner.main(JarSigner.java:74)
	at LargeJarEntry.main(LargeJarEntry.java:50)
	... 6 more

The lower bound on the memory was causing a different OOM error to be thrown. This
was caused by a java.io.tmpdir that had a huge amount of files. Although this is
a test system configuration problem (tmp dir needs to be cleaned up), the test 
should be fixed to set java.io.tmpdir to a directory with a reasonable number of 
files so that it doesn't come up again. We could set this to the current working
directory of the test. Normally this would not be a good idea because the temp dir
is used to gather entropy when generating secure random numbers, but since this is
a test it doesn't matter much.