May 2014 - core-libs-dev

JDK-8037382 Sequence and SequenceSet interface
by Sandipan Razzaque 13 May '14

13 May '14

Hi all, I'm looking to get started making contributions :-) I figured I'd start with something that was fairly prescriptive and mechanical just to get the hang of the process. Two questions if I may, as per the contribution guide: * Is anyone already working on the above item? (I do not wish to duplicate effort.) * Are there any objections to the changes already laid out in the ticket? If all is well, I shall get started with a patch for review. Cheers, SR https://bugs.openjdk.java.net/browse/JDK-8037382 Sandipan Razzaque | www.sandipan.net

2 3

JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY]
by Brian Burkhalter 12 May '14

12 May '14

Hello, Issue: https://bugs.openjdk.java.net/browse/JDK-8026236 Patch: http://cr.openjdk.java.net/~bpb/8026236/webrev.00/ This test provides a rudimentary verification of isProbablePrime() by: 1 - checking that the first 100000 primes are correctly identified as probably prime 2 - checking that a random sample of positive integers does not reveal non-prime numbers which test as prime The test allows for specification of an alternate source file of prime numbers if one wants to run it by hand. The file of primes included in the patch was limited to 100000 values in the interest of keeping the file size small. I think that the range of random numbers used for the non-prime portion of the test (currently [0,100000)) needs to be reexamined, but I wanted to throw this out there for discussion as-is. I’ve extended the use of the j.u.stream API to the entire test as recommended by Paul in http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/021859.ht…. Thanks, Brian

5 15

RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix)
by Peter Levart 12 May '14

12 May '14

Hi, This is a preview of the effort to merge all 4 variants of UNIXProcess class into one source. Here's the bug: https://bugs.openjdk.java.net/browse/JDK-8000975 And here's the webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.02/ Per Alan's suggestion I have made the merged source (UNIXProcess.java) be a descendant of UNIXProcess.java.linux in mercurial history. This webrev also incorporates reaper thread pool changes for Solaris variant (this was the only variant not yet using thread pool) so that the changes are even simpler. Still missing is UNIX OS resolving based on os.name system property (Os.get() method). I couldn't find any official document about possible os.name values for different supported OSes. Does anyone have a pointer? Regards, Peter

8 44

Re: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError
by Staffan Larsen 12 May '14

12 May '14

I’ve looked at a random sample of these changes and they look ok. Since some of the changes are in non-serviceability code I have also added core-libs to the review thread. I’m sure you know this, but for the record: please don’t push this until jtreg with the fix has been promoted. Thanks, /Staffan On 25 mar 2014, at 13:07, Yekaterina Kantserova <yekaterina.kantserova(a)oracle.com> wrote: > Hi, > > Could I please have a review of this fix. > > webrev: http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8034960 > > When using @library in a JTreg test even @build need to be specify for all library files used by the test. If @build is not specified it can lead to intermittent failures when running tests concurrently, since javac implicit compilation and @library and -concurrency don't play well together. > > Verified locally since no JTreg with fix has been promoted yet. > > > Thanks, > Katja

4 10

epollWait blocks ,but why consume cpu
by fuyou 10 May '14

10 May '14

My program is build on Netty4 . In benchmark,i find the epollWait consume many cpu,the jstack is The stack of busy(10.4%) thread(30873/0x7899) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-9" prio=10 tid=0x00002aaac418a000 nid=0x7899 runnable [0x0000000045f9a000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c4cf1e0> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.4%) thread(30866/0x7892) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-2" prio=10 tid=0x00002aaac4252800 nid=0x7892 runnable [0x0000000045893000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c4d1990> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.4%) thread(30865/0x7891) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-1" prio=10 tid=0x00002aaab95c0800 nid=0x7891 runnable [0x0000000045792000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c47c0f0> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.3%) thread(30871/0x7897) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-7" prio=10 tid=0x00002aaac417f800 nid=0x7897 runnable [0x0000000045d98000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c676820> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.3%) thread(30869/0x7895) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-5" prio=10 tid=0x00002aaac4061800 nid=0x7895 runnable [0x0000000045b96000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c528d90> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.3%) thread(30867/0x7893) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-3" prio=10 tid=0x00002aaac4254800 nid=0x7893 runnable [0x0000000045994000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.NativeThread.current(Native Method) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:333) - locked <0x000000076c4c90c8> (a java.lang.Object) - locked <0x000000076c4c90b0> (a java.lang.Object) at io.netty.buffer.PooledUnsafeDirectByteBuf.getBytes(PooledUnsafeDirectByteBuf.java:208) -- The stack of busy(10.2%) thread(30874/0x789a) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-10" prio=10 tid=0x00002aaac418c800 nid=0x789a runnable [0x000000004609b000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c5a70b0> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.2%) thread(30872/0x7898) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-8" prio=10 tid=0x00002aaac4187800 nid=0x7898 runnable [0x0000000045e99000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c62f290> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.2%) thread(30870/0x7896) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-6" prio=10 tid=0x00002aaac4190800 nid=0x7896 runnable [0x0000000045c97000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c45e320> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.2%) thread(30868/0x7894) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-4" prio=10 tid=0x00002aaac405b000 nid=0x7894 runnable [0x0000000045a95000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c6c2660> (a io.netty.channel.nio.SelectedSelectionKeySet) [yubao.fyb@vkvm169051 ~]$ cat busy_thread_20140509104529|grep 'NETTYSERVER-WORKER' -A6 -B2 The stack of busy(10.4%) thread(30873/0x7899) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-9" prio=10 tid=0x00002aaac418a000 nid=0x7899 runnable [0x0000000045f9a000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c4cf1e0> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.4%) thread(30866/0x7892) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-2" prio=10 tid=0x00002aaac4252800 nid=0x7892 runnable [0x0000000045893000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c4d1990> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.4%) thread(30865/0x7891) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-1" prio=10 tid=0x00002aaab95c0800 nid=0x7891 runnable [0x0000000045792000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c47c0f0> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.3%) thread(30871/0x7897) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-7" prio=10 tid=0x00002aaac417f800 nid=0x7897 runnable [0x0000000045d98000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c676820> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.3%) thread(30869/0x7895) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-5" prio=10 tid=0x00002aaac4061800 nid=0x7895 runnable [0x0000000045b96000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c528d90> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.3%) thread(30867/0x7893) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-3" prio=10 tid=0x00002aaac4254800 nid=0x7893 runnable [0x0000000045994000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.NativeThread.current(Native Method) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:333) - locked <0x000000076c4c90c8> (a java.lang.Object) - locked <0x000000076c4c90b0> (a java.lang.Object) at io.netty.buffer.PooledUnsafeDirectByteBuf.getBytes(PooledUnsafeDirectByteBuf.java:208) -- The stack of busy(10.2%) thread(30874/0x789a) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-10" prio=10 tid=0x00002aaac418c800 nid=0x789a runnable [0x000000004609b000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c5a70b0> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.2%) thread(30872/0x7898) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-8" prio=10 tid=0x00002aaac4187800 nid=0x7898 runnable [0x0000000045e99000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c62f290> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.2%) thread(30870/0x7896) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-6" prio=10 tid=0x00002aaac4190800 nid=0x7896 runnable [0x0000000045c97000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c45e320> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.2%) thread(30868/0x7894) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-4" prio=10 tid=0x00002aaac405b000 nid=0x7894 runnable [0x0000000045a95000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c6c2660> (a io.netty.channel.nio.SelectedSelectionKeySet) epollWait(...) blocks.why the consume cpu? has any idea to reduce cpu I also asked the question in Netty github<https://github.com/netty/netty/issues/2465> ============================================= fuyou001 Best Regards

3 3

Build failures on solaris
by Eric McCorkle 09 May '14

09 May '14

I am currently seeing build failures on solaris, coming from within the JDK repo: /opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/cc -DTRACING -DMACRO_MEMSYS_OPS -DBREAKPTS -D_BIG_ENDIAN= -DSOLARIS -DARCH='"sparcv9"' -Dsparcv9 -DNDEBUG -DTRIMMED -DRELEASE='"1.9.0-internal"' -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include/solaris -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/javavm/export -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/javavm/export -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/native/common -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/common -m64 -D__solaris__ -xc99=%none -xCC -errshort=tags -Xa -v -mt -W0,-noglobal -KPIC -xstrconst -xregs=no%appl -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/gensrc_headers -errtags -errwarn=%all -g -xs -xO2 -Wc,-Qrm-s -Wc,-Qiselect-T0 -DTHIS_FILE='"SolarisVirtualMachine.c"' -c -xMMD -xMF /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.d.tmp -o /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o /tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", line 1: empty character constant "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", line 1: syntax error before or at: '' gmake[2]: *** [/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o] Error 1 This is blocking integration of patches that need to go in promptly. This needs to be addressed ASAP.

4 8

JDK 9 RFR of 8042478: Include Mersenne primes in BigInteger primality testing
by Brian Burkhalter 08 May '14

08 May '14

Hello, This follows from a prior discussion thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-May/026771.html. Issue: https://bugs.openjdk.java.net/browse/JDK-8042478 Patch: http://cr.openjdk.java.net/~bpb/8042478/webrev.00/ Adds a test of the first 19 Mersenne primes. The remainder of the exponent list is commented out as it takes too long to run. The value 19 appears to give a reasonable execution time. The largest Mersenne prime tested is 285542542228902608580607. Thanks, Brian

2 3

about Selector.select is block ,but jstack thread is runnable
by fuyou 08 May '14

08 May '14

the jstack: NETTYSERVER-WORKER-19-thread-4" prio=10 tid=0x00000000136d3800 nid=0x75dc runnable [0x00000000499be000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) - locked <0x000000076ce96e58> (a io.netty.channel.nio.SelectedSelectionKeySet) - locked <0x000000076ce96658> (a java.util.Collections$UnmodifiableSet) - locked <0x000000076ce85be0> (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:618) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:306) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) at java.lang.Thread.run(Thread.java:745) the select doc : /** * Selects a set of keys whose corresponding channels are ready for I/O * operations. * * <p> This method performs a blocking <a href="#selop">selection * operation</a>. It returns only after at least one channel is selected, * this selector's {@link #wakeup wakeup} method is invoked, or the current * thread is interrupted, whichever comes first. </p> * * @return The number of keys, possibly zero, * whose ready-operation sets were updated * * @throws IOException * If an I/O error occurs * * @throws ClosedSelectorException * If this selector is closed */ public abstract int select() throws IOException; so the select is blocck unitl a channel is selected, but the jstack java.lang.Thread.State: is RUNNABLE,why not is BLOCKED. the offical api explain BLOCKED : public static final Thread.State BLOCKEDThread state for a thread blocked waiting for a monitor lock. A thread in the blocked state is waiting for a monitor lock to enter a synchronized block/method or reenter a synchronized block/method after calling Object.wait. because that's Select block until a channel is selected(not blocked waiting for a monitor lock) ,so it not the thread state BLOCKED. am i right ? -- ============================================= fuyou001 Best Regards

2 1

8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour
by Mike Duigou 07 May '14

07 May '14

Hello all; Recently HotSpot gained additional support for transactional memory, <https://bugs.openjdk.java.net/browse/JDK-8031320>. This patch is a libraries followon to that change. RTM and other transactional memory implementations benefit from clustering writes towards the end of the transaction whenever possible. This change optimizes the behaviour of two collection classes, Hashtable and Vector by moving several field updates to cluster them together near the end of the transaction. Yes, we know, these are obsolete collections but these two classes were used as the basis for the original benchmarking and evaluation during the development of the transactional memory JVM features. Future changes providing similar optimizations to other collections will be pursued when it can be shown they offer value and don't add a cost to non TM performance (TM is not yet a mainstream feature). https://bugs.openjdk.java.net/browse/JDK-8020860 http://cr.openjdk.java.net/~mduigou/JDK-8020860/0/webrev/ It is not expected that this change will have any meaningful impact upon performance (either positive or negative) outside of TM-enabled configurations. The main change is to move existing field updates towards the end of the transaction and avoid conditionals between field updates. There is a slight behaviour change introduced in this changeset. Previously some methods updated the modcount unconditionally updated even when an ArrayIndexOutOfBoundsException was subsequently thrown for an invalid index and the Vector was not modified. With this change the modcount will only be updated if the Vector is actually changed. It is not expected that applications will have relied or should have relied on this behaviour. Mike

6 17

RFR: 8042243: Map shared archive to preallocated static address
by Yumin Qi 07 May '14

07 May '14

Hi, Please have codereview for 8042243: Map shared archive to preallocated static address webrev: http://cr.openjdk.java.net/~minqi/8042243/webrev00/ bug: https://bugs.openjdk.java.net/browse/JDK-8042243 Summary: Mapping shared archive (jsa) some time fail due to ASLR (Address space layout randomization) on 32bit Linux platforms. To solve we come up with mapping shared archive to preallocated static space since with Linux and the GCC compiler, the BSS section in the main executable is not randomized, instead, the variable address in the BSS section is fixed at build time. The tests also showed the extra 32M space will NOT affect java memory setting though it seems 32M virtual address space always allocated no matter it is used or not (If -XX:ShareBaseAddress supply alternative address for dumping, the static address will be ignored.) Note the changes is for 32 bit Linux only. Tests: JPRT, manual test for archive sharing. Thanks Yumin

3 5