Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

> > > >> Which reminds me - do you propose to support the POSIX real-time signals? >>> >> No, I don't believe the VM supports them; it is an implementation >> limitation. >> > > Not sure what you mean here. The VM doesn't use them - which kind-of makes > them ideal for application code use as they

Re: RFR: 8148446: (tz) Support tzdata2016a

Hi Ramanand, I noticed that the zones in Yakutsk Time [1] seem to have their own names, such as "Khandyga Time" for Asia/Khandyga, and you seem to follow that convention for Asia/Chita. That causes some mismatch between the long names and abbreviations. I dag out some past tzdata fixes to se

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On Feb 2, 2016, at 11:25 AM, Mikael Vidstedt wrote: > Please review this change which introduces a Copy::conjoint_swap and an > Unsafe.copySwapMemory method to call it from Java, along with the necessary > changes to have java.nio.Bits call it instead of the Bits.c code. > > http://cr.openjdk.j

Re: JDK 9 RFR of JDK-8149003: Mark more jdk_core tests as intermittently failing

Hi Amy, Looks fine; thanks, -Joe On 2/3/2016 10:22 PM, Amy Lu wrote: java/net/NetworkInterface/NetworkInterfaceStreamTest.java java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java java/rmi/Naming/DefaultRegistryPort.java java/rmi/transport/closeServerSocket/CloseServerSocket.java Above

Re: JDK 9 RFR of JDK-8149003: Mark more jdk_core tests as intermittently failing

s/May/Amy ;-) -Chris. On 4 Feb 2016, at 06:23, Chris Hegarty wrote: > Seems reasonable to me May. > > -Chris. > > On 4 Feb 2016, at 06:22, Amy Lu wrote: > >> java/net/NetworkInterface/NetworkInterfaceStreamTest.java >> java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java >> java/rmi/N

Re: JDK 9 RFR of JDK-8149003: Mark more jdk_core tests as intermittently failing

Seems reasonable to me May. -Chris. On 4 Feb 2016, at 06:22, Amy Lu wrote: > java/net/NetworkInterface/NetworkInterfaceStreamTest.java > java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java > java/rmi/Naming/DefaultRegistryPort.java > java/rmi/transport/closeServerSocket/CloseServerSocket

JDK 9 RFR of JDK-8149003: Mark more jdk_core tests as intermittently failing

java/net/NetworkInterface/NetworkInterfaceStreamTest.java java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java java/rmi/Naming/DefaultRegistryPort.java java/rmi/transport/closeServerSocket/CloseServerSocket.java Above tests are known to fail intermittently, this patch is to mark the test a

Re: RFR:JDK-8146747:java.time.Duration.toNanos() and toMillis() exception on negative durations

Hi all, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8146747/webrev.01/ Regards, Nadeesh On 2/3/2016 5:48 PM, nadeesh tv wrote: Hi Shinya, Thnx. I will update it. Regards, Nadeesh On 2/3/2016 5:41 PM, ShinyaYoshida wrote: Hi Nadeesh, Almost LGTM!(But I'm not a reviewer;) ) H

RFR: 8148928: java/util/stream/test/**/SequentialOpTest.java timed out intermittently

Hi everyone, Would you please help to review the fix for bug https://bugs.openjdk.java.net/browse/JDK-8148928, java/util/stream/test/**/SequentialOpTest.java timed out intermittently. webrev: http://cr.openjdk.java.net/~mli/8148928/webrev.00/ Thank you -Hamlin

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

Hi Mikael, Can't really comment on the bit-twiddling details. A couple of minor style nits: - don't put "return" on a line by itself, include the first part of the return expression - spaces after commas in template definitions/instantiation The JVM_ENTRY_FROM_LEAF etc was a little mind twis

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

On 4/02/2016 7:15 AM, Roger Riggs wrote: Hi David, On 2/2/2016 10:05 PM, David Holmes wrote: On 3/02/2016 8:08 AM, Stuart Marks wrote: Hi Roger, It will be good to get this into the JDK. Lots of people have been asking for this. I think this API is a big mistake. The primary usecase seems t

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

Adding back hotspot-runtime-dev On 4/02/2016 2:07 AM, Roger Riggs wrote: Hi, The current wording is explicit about signal support being implementation and os dependent, it can say its release dependent too. So you think an API that is implementation dependent, OS dependent and release depend

ObjectInputStream SPI

In light of recent examples of gadget deserialization attacks, I believe we need an OIS SPI. While OIS functionality can be overridden, there's no way to ensure this can be done for all uses of OIS. I believe this is necessary for security reasons, to allow Serialization to be completely disab

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

On 2/2/16 7:05 PM, David Holmes wrote: On 3/02/2016 8:08 AM, Stuart Marks wrote: It will be good to get this into the JDK. Lots of people have been asking for this. I think this API is a big mistake. The primary usecase seems to be control-C interception for utilities like jshell. Adding a g

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

Hi David, On 2/2/2016 10:05 PM, David Holmes wrote: On 3/02/2016 8:08 AM, Stuart Marks wrote: Hi Roger, It will be good to get this into the JDK. Lots of people have been asking for this. I think this API is a big mistake. The primary usecase seems to be control-C interception for utilities

Re: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError

Hello! Here's the updated webrev with rangeCheckForAdd() restored in both AbstractList and ArrayList. http://cr.openjdk.java.net/~igerasim/8079136/07/webrev/ The fix was built/tested successfully on all supported platforms. Sincerely yours, Ivan On 02.02.2016 9:55, Martin Buchholz wrote: On

Re: [9] RFR: 8144593: Suppress not recognized property/feature warning messages from SAXParser

Looks good Aleksej! -Joe On 2/3/2016 10:19 AM, Aleksej Efimov wrote: Hi, Please, help to review the fix for JDK-8144593 bug [1] in jaxp area: http://cr.openjdk.java.net/~aefimov/8144593/9/00/ Problem: JDK produces warnings when non-default parser implementation is used and this parser doesn

RFR (S) 8148936: Adapt UUID.toString() to Compact Strings

Hi, JDK-8006627 did the JavaLangAccess hack to improve UUID.toString() performance: public String toString() { char[] chars = new char[36]; jla.formatUnsignedLong(mostSigBits >> 32, 4, chars, 0, 8); chars[8] = '-'; jla.formatUnsignedLong(mostSigBits >> 16, 4, c

[9] RFR: 8144593: Suppress not recognized property/feature warning messages from SAXParser

Hi, Please, help to review the fix for JDK-8144593 bug [1] in jaxp area: http://cr.openjdk.java.net/~aefimov/8144593/9/00/ Problem: JDK produces warnings when non-default parser implementation is used and this parser doesn't support jaxp features/properties. The quantity of such messages can

RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

Hi, Alan. > Good to have this in but now we need to decide on where it > should live. It's JDK-specific so we'll need it exported > by a JDK module rather than java.base. 8144062 was next on my list. Do you have any suggestions for the module? Of the existing modules in the jdk repository,

[DING] Re: [PING] Potential infinite waiting at JMXConnection#createConnection

Hi all, Could someone please review and sponsor this fix ? I write the details of this issue again. Please review it. =Problem= Potential infinite waiting at TCPChannel#createConnection. This method flushes the DataOutputStream without the socket timeout settings when choose stream protocol [1].

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Thanks for the comments Alan. Responses in-line. >> I created a new webrev, >> http://cr.openjdk.java.net/~sdrach/8132734/webrev.05/ >> , that implements >> what I outlined above. In particular I enhanced the JarEntryIterator class >>

Re: RFR JDK-7071819: To support Extended Grapheme Clusters in Regex

Hi Peter, Thanks for the review and suggestion. This appears to be a better approach. I was wondering if I should go this way to cache those lookup tables as well, but ... Webrev has been updated as suggested. Thanks! Sherman On 2/3/16 3:26 AM, Peter Levart wrote: Hi Again, I also have a

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On 02/03/2016 04:13 PM, Mikael Vidstedt wrote: > > On 2016-02-03 01:43, Andrew Haley wrote: >> On 02/02/16 19:25, Mikael Vidstedt wrote: >>> Please review this change which introduces a Copy::conjoint_swap and an >>> Unsafe.copySwapMemory method to call it from Java, along with the >>> necessary c

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On 2016-02-03 01:43, Andrew Haley wrote: On 02/02/16 19:25, Mikael Vidstedt wrote: Please review this change which introduces a Copy::conjoint_swap and an Unsafe.copySwapMemory method to call it from Java, along with the necessary changes to have java.nio.Bits call it instead of the Bits.c code

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

Hi, The current wording is explicit about signal support being implementation and os dependent, it can say its release dependent too. Roger On 2/3/2016 11:00 AM, Chris Hegarty wrote: On 03/02/16 15:43, Thomas Stüfe wrote: On Wed, Feb 3, 2016 at 4:20 PM, Thomas Stüfe wrote: On Wed, Feb

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

On 03/02/16 15:43, Thomas Stüfe wrote: On Wed, Feb 3, 2016 at 4:20 PM, Thomas Stüfe wrote: On Wed, Feb 3, 2016 at 4:05 AM, David Holmes wrote: On 3/02/2016 8:08 AM, Stuart Marks wrote: Hi Roger, It will be good to get this into the JDK. Lots of people have been asking for this. I thin

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

On Wed, Feb 3, 2016 at 4:20 PM, Thomas Stüfe wrote: > > > On Wed, Feb 3, 2016 at 4:05 AM, David Holmes > wrote: > >> On 3/02/2016 8:08 AM, Stuart Marks wrote: >> >>> Hi Roger, >>> >>> It will be good to get this into the JDK. Lots of people have been >>> asking for this. >>> >> >> I think this A

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

Hi Chris, On Wed, Feb 3, 2016 at 4:22 PM, Chris Hegarty wrote: > On 03/02/16 15:20, Thomas Stüfe wrote: > >> On Wed, Feb 3, 2016 at 4:05 AM, David Holmes >> wrote: >> >> On 3/02/2016 8:08 AM, Stuart Marks wrote: >>> >>> Hi Roger, It will be good to get this into the JDK. Lots of peopl

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

On 03/02/16 15:20, Thomas Stüfe wrote: On Wed, Feb 3, 2016 at 4:05 AM, David Holmes wrote: On 3/02/2016 8:08 AM, Stuart Marks wrote: Hi Roger, It will be good to get this into the JDK. Lots of people have been asking for this. I think this API is a big mistake. The primary usecase seems

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

On Wed, Feb 3, 2016 at 4:05 AM, David Holmes wrote: > On 3/02/2016 8:08 AM, Stuart Marks wrote: > >> Hi Roger, >> >> It will be good to get this into the JDK. Lots of people have been >> asking for this. >> > > I think this API is a big mistake. The primary usecase seems to be > control-C interce

Re: RFR-8148748: ArrayList.subList().spliterator() is not late-binding

On Wed, Feb 3, 2016 at 4:20 AM, Tagir F. Valeev wrote: > Some more thoughts about forEachRemaining: > > To me it seems that > if ((a = lst.elementData) != null) > is a redundant check as well as in current ArrayList implementation > elementData is never null. So it can be replaced with simple > a

Re: RFR(XS) 8148785: Update class file version to 53 for JDK-9

Hi Alan, Thanks for looking at the change. I'll drop the comment before checking it in. Harold On 2/3/2016 9:32 AM, Alan Bateman wrote: On 03/02/2016 14:12, harold seigel wrote: Hi Aleksey, Thanks for the review. The plan is to first change the runtime to accept version 53 files and

Re: RFR: JDK-8148955: libjimage.so compiled with wrong flags

On 03/02/2016 13:50, Erik Joelsson wrote: The library libjimage.so consists of C++ source files, but is currently setup to compile using CFLAGS_JDKLIB instead of CXXFLAGS_JDKLIB. On Solaris, these variables contain quite a few differences due to the compilers taking very different arguments.

Re: RFR(XS) 8148785: Update class file version to 53 for JDK-9

On 03/02/2016 14:12, harold seigel wrote: Hi Aleksey, Thanks for the review. The plan is to first change the runtime to accept version 53 files and then change the tools to generate them. Hopefully, this will reduce incompatibility problems. See JDK-8148651

Re: Stream.foldLeft, one more time (8133680)

Hi Tagir, I think this is reasonable, no objections. Naming-wise reduceLeft might fit better. Those default methods look good. We might be able to do a little better tweaking stuff in ForEachOps to avoid the array box, for some increase in code i.e. a clone of ForEachOps.ForEachOp. Testing-wi

Re: RFR(XS) 8148785: Update class file version to 53 for JDK-9

Hi Aleksey, Thanks for the review. The plan is to first change the runtime to accept version 53 files and then change the tools to generate them. Hopefully, this will reduce incompatibility problems. See JDK-8148651 for details. Thanks, Ha

Re: RFR: JDK-8148955: libjimage.so compiled with wrong flags

+1 (at least for the jdk code) Thanks Erik On 02/03/2016 08:50 AM, Erik Joelsson wrote: The library libjimage.so consists of C++ source files, but is currently setup to compile using CFLAGS_JDKLIB instead of CXXFLAGS_JDKLIB. On Solaris, these variables contain quite a few differences due to

RFR: JDK-8148955: libjimage.so compiled with wrong flags

The library libjimage.so consists of C++ source files, but is currently setup to compile using CFLAGS_JDKLIB instead of CXXFLAGS_JDKLIB. On Solaris, these variables contain quite a few differences due to the compilers taking very different arguments. This makes the build process very noisy in t

Re: RFR(XS) 8148785: Update class file version to 53 for JDK-9

On 02/03/2016 04:16 PM, harold seigel wrote: > Open webrevs: > http://cr.openjdk.java.net/~hseigel/bug_8148785.jdk/ > http://cr.openjdk.java.net/~hseigel/bug_8148785.hs/ +1 > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8148785 Description seems to imply we change the compiled c

RFR(XS) 8148785: Update class file version to 53 for JDK-9

Hi, Please review this small change to fix bug 8148785. The fix bumps the class file version to 53 for JDK-9. Open webrevs: http://cr.openjdk.java.net/~hseigel/bug_8148785.jdk/ http://cr.openjdk.java.net/~hseigel/bug_8148785.hs/ JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8

Re: RFR-8148838: Stream.flatMap(...).spliterator() cannot properly split after tryAdvance()

Hi Tagir, Test updates look good, thanks, that should reduce the test times on some of our test machines. I still disagree and pushing back on the support for splitting after partial traversal. It’s not a pattern i think we should encourage and propagate so such behaviour can be generally reli

RFR-8148748: ArrayList.subList().spliterator() is not late-binding

Hello! Here's the webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8148748/r1/ I noticed that list == null checks are never true, thus redundant, so I removed them. The list field is final and always assigned to the outer ArrayList instance. So it seems quite natural to make ArrayListSpliterato

Re: RFR-8148838: Stream.flatMap(...).spliterator() cannot properly split after tryAdvance()

Hello! Here's updated webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8148838/r2/ PS> My inclination is to keep this simple and not support splitting after partial traversal. PS> Sometimes splitting after partial traversal might be more complex PS> not support (e.g. ArrayList). In other case

Re: RFR:JDK-8146747:java.time.Duration.toNanos() and toMillis() exception on negative durations

Hi Shinya, Thnx. I will update it. Regards, Nadeesh On 2/3/2016 5:41 PM, ShinyaYoshida wrote: Hi Nadeesh, Almost LGTM!(But I'm not a reviewer;) ) However I've noticed that you don't use NANOS_PER_SECOND at L1223 and L1246. Is there some reason not to use it? Regards, shinyafox(Shinya Yoshida)

Re: RFR:JDK-8146747:java.time.Duration.toNanos() and toMillis() exception on negative durations

Hi Nadeesh, Almost LGTM!(But I'm not a reviewer;) ) However I've noticed that you don't use NANOS_PER_SECOND at L1223 and L1246. Is there some reason not to use it? Regards, shinyafox(Shinya Yoshida) 2016-02-01 15:18 GMT+09:00 nadeesh tv : > Hi all, > > Please review following > > Bug Id : https

Re: RFR JDK-7071819: To support Extended Grapheme Clusters in Regex

Hi Again, I also have a comment on the implementation of the hash table and it's GC-ness. You keep the string pool under a SoftReference because it is the biggest object so it makes most sense to clear it when heap becomes full. Other arrays are kept strongly reachable, but you re-generate the

Re: RFR JDK-7071819: To support Extended Grapheme Clusters in Regex

Hi Sherman, I don't currently have any idea how to squeeze the hashtable any more further. It is already very compact in my opinion. But I noticed a data race that could result in navigating the half-initialized data structure. It is a classical unsafe publication bug. It has been present bef

Re: RFR:JDK-8146747:java.time.Duration.toNanos() and toMillis() exception on negative durations

Yes, looks fine thanks Stephen On 1 February 2016 at 06:18, nadeesh tv wrote: > Hi all, > > Please review following > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8146747 > > Solution: Handled the negative duration separately > > webrev : http://cr.openjdk.java.net/~ntv/8146747/webrev.00/

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On 02/02/16 19:25, Mikael Vidstedt wrote: > Please review this change which introduces a Copy::conjoint_swap and an > Unsafe.copySwapMemory method to call it from Java, along with the > necessary changes to have java.nio.Bits call it instead of the Bits.c code. There doesn't seem to be any way t

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 03/02/2016 02:24, Steve Drach wrote: I created a new webrev, http://cr.openjdk.java.net/~sdrach/8132734/webrev.05/ , that implements what I outlined above. In particular I enhanced the JarEntryIterator class and I added additional

Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

On 03/02/2016 03:17, Iris Clark wrote: Hi, Mandy. Thanks so much for pushing the changeset for the initial implementation of jdk.Version! Good to have this in but now we need to decide on where it should live. It's JDK-specific so we'll need it exported by a JDK module rather than java.base.