Re: RFR JDK-8176379: java.util.Base64 mime encoder behaves incorrectly if initialized with a line length of size 1-3

On 29/01/2018 17:52, Xueming Shen wrote: Actually I have a dedicated test case for "mime encoder maxlen". *test/jdk/java/util/Base64/Base64GetEncoderTest.java* I have updated it to test the negative and the < 4 maxlen. http://cr.openjdk.java.net/~sherman/8176379/webrev/ webrev has been

[PATCH] GPU Exploitation Infrastructure

This patch provides the infrastructure to enable the exploitation of a GPU by the compiler to accelerate certain suitable Java constructs. When enabled, a suitable compiler can attempt to accelerate the following Java constructs by launching the corresponding lambda expression on the GPU:

Re: RFR: 8011697(ScriptEngine "js" randomly means either "rhino" or "nashorn", but should instead select one)

+1 (with the copyright header change suggested by Alan) -Sundar On 30/01/18, 8:28 PM, Alan Bateman wrote: On 30/01/2018 09:17, Srinivas Dama wrote: Hi, Please review the revised webrev at http://cr.openjdk.java.net/~sdama/8011697/webrev.01/ for

Re: [PATCH] GPU Exploitation Infrastructure

On 30/01/2018 13:55, Ben Walsh wrote: This patch provides the infrastructure to enable the exploitation of a GPU by the compiler to accelerate certain suitable Java constructs. When enabled, a suitable compiler can attempt to accelerate the following Java constructs by launching the

Re: RFR: 8011697(ScriptEngine "js" randomly means either "rhino" or "nashorn", but should instead select one)

On 30/01/2018 09:17, Srinivas Dama wrote: Hi, Please review the revised webrev at http://cr.openjdk.java.net/~sdama/8011697/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8011697 The updated patch to ScriptEngineManager looks okay. Can you replace the copyright header in the

Re: JDK-8196298: Add null Reader and Writer

On 29/01/2018 22:55, Brian Burkhalter wrote: I made a few minor changes to the CSR [1] verbiage. Probably the nullWriter() documentation should also be updated to explicitly mention all variants of both append() and write(). It could although limiting it to the abstract methods should be fine

Re: RFR: 8196331: Optimize Character.digit for latin1 input

+1 On Jan 30, 2018, at 2:40 AM, Claes Redestad wrote: The ASM is harder than usual to follow and compare since everything is inlined aggressively, but it seems that since CharacterDataLatin1 is only invoked for 0 <= ch < 256 (invariant established in

Re: RFR JDK-8176379: java.util.Base64 mime encoder behaves incorrectly if initialized with a line length of size 1-3

Hi, Base64GetEncoderTest does not need to test the negative values more than once. Otherwise, looks fine. Roger On 1/30/2018 9:31 AM, Alan Bateman wrote: On 29/01/2018 17:52, Xueming Shen wrote: Actually I have a dedicated test case for "mime encoder maxlen".

Re: RFR: 8196331: Optimize Character.digit for latin1 input

OK! A surprising increase in code size. Thanks for checking. Paul. > On Jan 30, 2018, at 2:40 AM, Claes Redestad wrote: > > The ASM is harder than usual to follow and compare since everything is > inlined aggressively, but it seems that since CharacterDataLatin1 is

Re: JDK-8196298: Add null Reader and Writer

> Am 30.01.2018 um 16:02 schrieb Alan Bateman : > > On 29/01/2018 22:55, Brian Burkhalter wrote: >> I made a few minor changes to the CSR [1] verbiage. Probably the >> nullWriter() documentation should also be updated to explicitly mention all >> variants of both

Re: RFR 8181594: Efficient and constant-time modular arithmetic

+core-libs-dev On 1/26/2018 4:06 PM, Adam Petcher wrote: JBS: https://bugs.openjdk.java.net/browse/JDK-8181594 Webrev: http://cr.openjdk.java.net/~apetcher/8181594/webrev.00/ This is a code review for the field arithmetic that will be used in implementations of X25519/X448 key agreement, the

Re: [PATCH] Inefficient ArrayList.subList().toArray()

On Mon, Jan 29, 2018 at 1:02 PM, Martin Buchholz wrote: > I'm going to expedite this a little since we are building further changes > on top. > > 8196207: Inefficient ArrayList.subList().toArray() > http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166- >

RE: RFR: 8011697(ScriptEngine "js" randomly means either "rhino" or "nashorn", but should instead select one)

Hi, Please review the revised webrev at http://cr.openjdk.java.net/~sdama/8011697/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8011697 Regards, Srinivas -Original Message- From: Alan Bateman Sent: Monday, December 11, 2017 10:05 PM To: Srinivas Dama

Re: [PATCH] GPU Exploitation Infrastructure

On 31/01/2018 1:35 AM, Alan Bateman wrote: On 30/01/2018 13:55, Ben Walsh wrote: This patch provides the infrastructure to enable the exploitation of a GPU by the compiler to accelerate certain suitable Java constructs. When enabled, a suitable compiler can attempt to accelerate the following

JDK-8166339, Code conversion working behavior was changed for x-IBM834

Hi, Please help review the change for JDK-8166339. issue: https://bugs.openjdk.java.net/browse/JDK-8166339 webrev: http://cr.openjdk.java.net/~sherman/8166339/webrev This is a regression triggered by issue: https://bugs.openjdk.java.net/browse/JDK-8008386 webrev:

RFR 8195059: Update java.net Socket and DatagramSocket implementations to use Cleaner

Please review changes to replace finalizers in socket, datagram, and multicast networking with Cleaner based release of the raw file descriptors.  Each FileDescriptor is registered for cleanup after the raw fd (or handle) is assigned.  Normal calls to close unregister the cleaner before using

Re: Possible addition of a default 'getOne' method on Iterable?

Basically, but it's annoying and ugly to write most likely sub-optimal has problems with things like synchronized collections On 01/31/2018 12:28 AM, Zheka Kozlov wrote: Isn't iterable.getOne() the same as iterable.iterator().next()? 2018-01-31 12:15 GMT+07:00 Dave Brosius

Re: [PATCH] GPU Exploitation Infrastructure

Project Sumatra was looking at GPU use: https://wiki.openjdk.java.net/display/Sumatra/Main It's inactive though. David On 31/01/2018 7:46 AM, David Holmes wrote: On 31/01/2018 1:35 AM, Alan Bateman wrote: On 30/01/2018 13:55, Ben Walsh wrote: This patch provides the infrastructure to enable

Collections.addAll: remove outdated performance advice and add a note about atomicity

Hello! I suggest a patch for java.util.Collections#addAll JavaDoc: --- Collections.java2018-01-31 09:39:31.599107500 +0700 +++ Collections.java.patched2018-01-31 09:51:11.929059600 +0700 @@ -5406,4 +5406,8 @@ * The behavior of this convenience method is identical to that of - *

Re: Collections.addAll: remove outdated performance advice and add a note about atomicity

I tried to tackle this here: http://openjdk.markmail.org/thread/eet2zd6ig3pfpv5g and it's still on my TODO list but not likely to get to top spot soon. On Tue, Jan 30, 2018 at 7:00 PM, Tagir Valeev wrote: > Hello! > > I suggest a patch for java.util.Collections#addAll

Re: [JDK 11] RFR 8196211: Move two sun/nio/cs tests into OpenJDK

Thank you Paul. Pushed as suggested :-) Thanks, Amy On 30/01/2018 12:37 AM, Paul Sandoz wrote: That’s better :-) If you wanna make it static i suggest:   s/inputFileName/INPUT_FILE_NAME although there is little benefit here since all access is local to main. Up to you to make local or keep

Possible addition of a default 'getOne' method on Iterable?

Greetings, sorry if this has been asked before, but has there been any consideration for adding a default T getOne() {     Iterator it = iterator();     if (!it.hasNext()) {     throw new NoSuchElementException();     }     return it.next(); } on the Iterable interface? It is often

Re: Possible addition of a default 'getOne' method on Iterable?

Isn't iterable.getOne() the same as iterable.iterator().next()? 2018-01-31 12:15 GMT+07:00 Dave Brosius : > Greetings, > > > sorry if this has been asked before, but has there been any consideration > for adding a > > default T getOne() { > > Iterator it =

Re: RFR: 8196331: Optimize Character.digit for latin1 input

Hi, not sure what you're suggesting, exactly, but it seems Charset coders generate String literals which are then unpacked to char[]/byte[]'s in static blocks. While constructing arrays from String literals might have been a startup optimization in the past, it is now mainly a workaround to

Re: [8u-dev] RFR - 8156824: com.sun.jndi.ldap.pool.PoolCleaner should clear its context class loader

> On 26 Jan 2018, at 16:40, Rob McKenna wrote: > > Hi folks, > > I'd like to backport this change to 8u-dev. > > The changes are straightforward enough but 8u needs some changes that > were made to InnocuousThread. (strictly it doesn't need all of the > changes I've

Re: RFR: 8196331: Optimize Character.digit for latin1 input

The ASM is harder than usual to follow and compare since everything is inlined aggressively, but it seems that since CharacterDataLatin1 is only invoked for 0 <= ch < 256 (invariant established in CharacterData.of(int ch)) then the compiler is able to elide bounds check entirely when the byte[]