JDK-8148540 : sun/nio/ch/TestMaxCachedBufferSize.java fails on 32bit system
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 8u102,9
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-01-29
  • Updated: 2020-04-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8147468 - (bf) Allow users to bound the size of buffers cached in the per-thread buffer caches
Relates :  
JDK-8148627 - RestrictTestMaxCachedBufferSize.java to 64-bit platforms
Description
sun/nio/ch/TestMaxCachedBufferSize.java

This test is newly introduced in JDK-8147468, it fails on 32bit system.

Example failure log for Windows 32bit:

#section:main
----------messages:(3/145)----------
command: main TestMaxCachedBufferSize
reason: User specified action: run main/othervm TestMaxCachedBufferSize 
elapsed time (seconds): 17.013
----------System.out:(12/785)----------
Threads 4 | Iterations 10000 | MaxBufferSize 9223372036854775807

 Worker   3 |     5000 Iters | Small     4950 Large       50 | Direct    6 /   16053K
 Worker   2 |     5000 Iters | Small     4960 Large       40 | Direct    6 /   16053K
 Worker   0 |     5000 Iters | Small     4944 Large       56 | Direct    6 /   16053K
 Worker   1 |     5000 Iters | Small     4955 Large       45 | Direct    6 /   16053K
 Worker   3 |    10000 Iters | Small     9902 Large       98 | Direct    6 /   16104K
 Worker   0 |    10000 Iters | Small     9890 Large      110 | Direct    5 /   12042K
 Worker   1 |    10000 Iters | Small     9905 Large       95 | Direct    5 /   12042K
 Worker   2 |    10000 Iters | Small     9909 Large       91 | Direct    5 /   12042K

Direct 5 / 12042K
----------System.err:(14/936)----------
java.lang.Error: inconsistent direct buffer total count, expected = 4, found = 5
	at TestMaxCachedBufferSize.checkDirectBuffers(TestMaxCachedBufferSize.java:178)
	at TestMaxCachedBufferSize.main(TestMaxCachedBufferSize.java:248)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:520)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92)
	at java.lang.Thread.run(Thread.java:804)

JavaTest Message: Test threw exception: java.lang.Error: inconsistent direct buffer total count, expected = 4, found = 5
Comments
Alan, Only running on 64-bit will of course work. But, it might also be error-prone in the long term (another library might create a direct buffer in the future?). We could introduce a back-door for tests to get hold of the buffer cache of a thread, enumerate over the cached buffers, and sanity-check that their size is as expected?
29-01-2016
Your approach should work but just to say that class loading (on 32-bit) will result in buffer usages that might interfere.
29-01-2016
Alan, yeah that'd explain it. Any ideas of how to change the test to do the proper sanity checking at the end? Given the extra direct buffer would be of unknown size, we can't deduce anything about the cashed buffers by looking at the total. Aha. Would this work: * store the count / size of total direct buffers before we fire the workers * subtract the stored values from what we find at the end and do sanity checking on the results?
29-01-2016
Alan, I posted my previous comment before seeing your updated note on only running on 64-bit. Either way is fine with me. Is it worth trying the scheme I described earlier?
29-01-2016
The jimage implementation on 32-bit uses direct buffers. It uses memory mapping on 64-bit. The simplest thing for now might be to add an @requires so that it only runs on 64-bit.
29-01-2016
Apologies for this, I had only tested on 64-bit. So, this is curious: I'm expecting only one direct byte buffer to be cached per worker thread. In the above output we end up with one extra. Anyone knows where the extra buffer is coming from?
29-01-2016