Re: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible

On 07/14/2017 02:47 PM, Claes Redestad wrote: >> For extra points remove the superfluous null assignment of >> `signature` and `field` ( as well as `offset` ). > > 'field' is final so that'd make javac cry bloody murder, but I fixed the > rest and cleaned up a bit for consistency: > >

Re: 8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel()

On 06/27/2017 08:50 AM, Langer, Christoph wrote: > So, waiting for comments from other experts... >> Webrev: http://cr.openjdk.java.net/~horii/8179527/webrev.00/ This patch is fine as stated. Without volatile, there is a benign data race on the bugLevel field, which is okay, assuming

Re: [jdk9] RFR 8181442 Deprecate sun.misc.Unsafe.defineClass

On 06/07/2017 08:22 PM, Paul Sandoz wrote: > diff -r ed1e99c1bba2 src/jdk.unsupported/share/classes/sun/misc/Unsafe.java > --- a/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java Wed Jun 07 > 06:45:09 2017 -0700 > +++ b/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java Wed Jun 07 >

Re: RFR: 8181147: JNI_GetStringPlatformChars should have a fast path for UTF-8

On 05/26/2017 07:58 PM, Claes Redestad wrote: > However, UTF-8 is missing, which is a shame since we have optimized > utilities for converting from a String to UTF-8-encoded char* (since > this is the native encoding used by HotSpot internally). > > Webrev:

Re: JDK 10 RFR of 8176894: Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute in TreeMap

On 03/16/2017 08:04 PM, Sergey Kuksenko wrote: > http://cr.openjdk.java.net/~skuksenko/corelibs/utils/8176894/webrev.00/ Looks good. I assume there are enough tests to cover these paths? *) Missing whitespace (multiple times in the similar line): if(replaceOld) { Thanks, -Aleksey

Re: [10] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine

On 03/01/2017 06:11 PM, Claes Redestad wrote: > Sure, with a bit of fix-up this drops another 170k executed bytecodes > to read in the java.security file (original: 1882k, now: 980k): > > http://cr.openjdk.java.net/~redestad/8176041/jdk.02/ Ok, that's fine. This is slightly more idiomatic, you

Re: [10] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine

On 03/01/2017 04:34 PM, Claes Redestad wrote: > the properties line reader has some relevance to startup, e.g., > when reading the java.security file, and as more documentation > content has been added to this file it has been made apparent > that the handling of comment lines is inefficient due

Re: Forcing initialization of string concat INDY expressions

Hi, On 03/01/2017 07:36 AM, David Holmes wrote: > The INDY-fication of string concatenation has triggered a problem where a JVM > TI > agent's monitor-wait/ed callback hits an error path that uses string concat > which triggers a mass of indy related initialization, which in turn hits > monitor

Re: RFR 8175360 Error in Collectors.averagingXXX Java Doc

+1 -Aleksey On 02/22/2017 10:19 PM, Paul Sandoz wrote: > Hi > > Please review this small documentation fix to the averaging functions on > java.util.stream.Collectors. > > Paul. > > diff -r 29059b8ecc7f > src/java.base/share/classes/java/util/stream/Collectors.java > ---

Re: RFR (JDK 10) 8172298: Reduce memory churn when linking VarHandles operations

On 01/28/2017 12:10 AM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8172298-varhandle-link-reduce-memory/webrev/ Looks good, but I think the StringBuilder is inefficiently sized: it adds (parameterCount() - 2) chars in the loop, skipping the first and and then two after the

Re: Backport of JEP 254 (Compact Strings) to OpenJDK 8

On 01/12/2017 08:11 PM, John Platts wrote: > I am interested in OpenJDK 8 builds with JEP 254 (Compact Strings) support > backported from OpenJDK 9. I like the compact strings work that is being done > in JDK 9, but I am interested in a OpenJDK 8 build with backported JEP 254 > support since I am

Re: RFR 8170733: HashMap.HashIterator.remove method does not use cached value for the hash code.

On 12/05/2016 09:12 PM, Paul Sandoz wrote: > diff -r 5c9389804cbc src/java.base/share/classes/java/util/HashMap.java > --- a/src/java.base/share/classes/java/util/HashMap.java Mon Dec 05 > 12:53:53 2016 +0530 > +++ b/src/java.base/share/classes/java/util/HashMap.java Mon Dec 05 >

Re: RFR: 8170467: (reflect) Optimize SignatureParser's use of StringBuilders

On 11/29/2016 02:18 PM, Claes Redestad wrote: > please review this patch provided by Max Kanat-Alexander[1] to improve > performance of sun.reflect.generics.parser.SignatureParser by reducing > number of StringBuilders created and the rate at which they are resized > during typical usage. > >

Re: RFR: 8169880: Remove the sun.reflect.noCaches option

On 11/17/2016 04:33 PM, Claes Redestad wrote: > The undocumented sun.reflect.noCaches option was put in place as a > debugging aid when caching was added to core reflection[1], with the > intent to remove it once overly inefficient uses of reflection was > weeded out[2]. This appears to have been

Re: RFR: 8168640: (fc) Avoiding AtomicBoolean in FileInput/-OutputStream improves startup

On 10/25/2016 12:51 PM, Claes Redestad wrote: > Avoiding AtomicBoolean improves startup and footprint for a sample of > small applications: > > Webrev: http://cr.openjdk.java.net/~redestad/8168640/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8168640 I would generally disagree to

Re: RFR(XXS): 8166801: [s390] Add jvm.cfg file for Linux/s390x

On 10/05/2016 04:43 PM, Volker Simonis wrote: > can somebody please review the following trivial change which simply > adds a new jvm.cfg file for Linux/s390x: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/s390x/8166801/ > https://bugs.openjdk.java.net/browse/JDK-8166801 This looks okay

Re: RFR: 8167005: Comment on the need for an empty constructor in ArrayList$Itr

On 10/04/2016 12:50 PM, Claes Redestad wrote: > Webrev: http://cr.openjdk.java.net/~redestad/8167005/webrev.01/ OK. -Aleksey

Re: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

On 09/29/2016 07:50 PM, Rafael Winterhalter wrote: > I want to propose adding a method to the instrumentation API to receive an > instance of the current VM's instrumentation API. Currently, many > applications "self-attach" to gain such access. Unfortunately, this only > works on JDK-VMs but I

Re: RFR: 8166842: String.hashCode() has a non-benign data race

Peter, David, Would you mind discussing the theoretical topics on concurrency-interest@, for the benefits of others who don't track high-traffic OpenJDK list? Thanks, -Aleksey On 09/28/2016 03:24 PM, Peter Levart wrote: > > On 09/28/2016 03:05 PM, David Holmes wrote: >> On 28/09/2016 10:44 PM,

Re: RFR: 8166842: String.hashCode() has a non-benign data race

On 09/28/2016 02:44 PM, Peter Levart wrote: > http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String.hashCode/webrev.01/ +1, thanks. This is partially my fault for not spotting it earlier during the Compact Strings work. -Aleksey

Re: RFR: jsr166 jdk9 integration wave 11

On 09/21/2016 09:33 PM, Martin Buchholz wrote: > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ Looks fine. Multi-story predicates sure look better now... -Aleksey

Re: RFC: System.console().encoding()

On 09/15/2016 09:06 AM, Xueming Shen wrote: > Console is supposed to be a "char/String" based class, "encoding" > really should have no business here in its api. Simply for some > implementation convenience is really not a good reason to add such a > public method. Let's look at it this way:

RFC: System.console().encoding()

Hi, Claes pointed out that our own reflective hacks to figure out console encoding do not work anymore [1]. But, we need the console encoding for reliably printing on the console from within different sources. Note that you would normally just use System.console() and its PrintWriter, but reality

Re: RFR: jsr166 jdk9 integration wave 10

On 09/12/2016 07:57 PM, Martin Buchholz wrote: > is better spelled like this? > > 176 * setPendingCount(1); // only one pending, not two! > > I already struggled over the wording here hmmm ... how about > > // looks off by one, but correct! Yes, this is better. > I

Re: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore

On 09/12/2016 12:54 PM, Frank Yuan wrote: > Would you like to review http://cr.openjdk.java.net/~fyuan/8087303/webrev.01/? Not an expert in the XML parsing area, so only a cursory code review: ToStream.java: *) Bad camel casing: 113 protected boolean m_ispreserveSpace = false; *)

Re: RFR: jsr166 jdk9 integration wave 10

On 09/10/2016 08:21 PM, Martin Buchholz wrote: > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > > Mostly docs and tests. Looks good. Very nice use of (frequently overlooked) local classes in examples. Minor things: CountedCompleter.java: 176 *

Re: Review Request: JDK-8165346 j.l.ClassLoader.getDefinedPackage(String) throws NPE

On 09/09/2016 01:02 AM, Mandy Chung wrote: > Spec bug: missing @throws NPE if the specified name is null in the relevant > getPackage methods: > ClassLoader.getDefinedPackage, ClassLoader::getPackage, Package::getPackage > > Webrev at: >

Re: RFR 8165731 Reference to removed method in VarHandle JavaDoc

On 09/09/2016 12:18 AM, Paul Sandoz wrote: > diff -r 10d8bdeabfa5 > src/java.base/share/classes/java/lang/invoke/VarHandle.java > --- a/src/java.base/share/classes/java/lang/invoke/VarHandle.java Thu Sep > 08 09:59:54 2016 -0700 > +++

Re: RFR: 8165492: Reduce number of lambda forms generated by MethodHandleInlineCopyStrategy

On 09/08/2016 11:31 PM, Paul Sandoz wrote: >> On 8 Sep 2016, at 12:37, Claes Redestad wrote: On 09/08/2016 09:21 PM, Paul Sandoz wrote: Did you consider replacing the if block with an assert? presumably if it is non-zero it is an internal error? >>> >>>

Re: RFR: 8165492: Reduce number of lambda forms generated by MethodHandleInlineCopyStrategy

Hi, On 09/08/2016 08:03 PM, Claes Redestad wrote: > Webrev: http://cr.openjdk.java.net/~redestad/8165492/webrev.01/ It is a bit sad that we have to bust the doors with internal APIs, and not use the public API, thus robbing ourselves of the opportunity to optimize the public API for a wide range

Re: RFR(s): 4285505: deprecate java.lang.Compiler

On 09/07/2016 11:52 PM, Stuart Marks wrote: > Please review this small patch to deprecate java.lang.Compiler for removal. Yes, +1. This class is very confusing to have these days. -Aleksey

Re: Participating on https://bugs.openjdk.java.net/browse/JDK-8156070

On 09/06/2016 01:49 AM, Jonathan Bluett-Duncan wrote: > I decided to have a crack at "JDK-8134373 explore potential uses of > convenience factories within the JDK" today. I recognise it's only a P4 bug > and most likely won't be prioritised for Java 9, but I believe I found a > number of places

Re: RFR: JDK-8164547: Make java.lang.reflect.ClassLoaderValue public for internal use

On 08/22/2016 01:15 PM, Peter Levart wrote: > Webrev: > http://cr.openjdk.java.net/~plevart/jdk9-dev/ClassLoaderValue.public/webrev.01/ Looks good to me. AFAIU, making the classes public under the non-exported jdk.internal.loader package is fine. Thanks, -Aleksey

Re: Testing hotspot's Atomic::cmpxchg(jbyte*) ?

On 08/19/2016 03:03 PM, David Holmes wrote: > On 19/08/2016 7:37 PM, Aleksey Shipilev wrote: >> On 08/19/2016 12:26 PM, David Holmes wrote: >>> On 19/08/2016 5:40 PM, Aleksey Shipilev wrote: >>>> On 08/19/2016 10:13 AM, David Holmes wrote: >>>>>> No

Re: RFR: 8164451: Generate all zero and identity forms at link time

On 08/19/2016 01:08 PM, Claes Redestad wrote: > Webrev: http://cr.openjdk.java.net/~redestad/8164451/webrev.01/ Looks good. > This removes runtime generation of 2 classes from the test in > JDK-8086045, leaving only 2 generated forms to deal with to get down > to no(!) bytecode generation

Re: Testing hotspot's Atomic::cmpxchg(jbyte*) ?

On 08/19/2016 12:26 PM, David Holmes wrote: > On 19/08/2016 5:40 PM, Aleksey Shipilev wrote: >> On 08/19/2016 10:13 AM, David Holmes wrote: >>>> Now it might be cleaner to ditch Java version from Unsafe, and make >>>> native entry points like Unsafe_CompareAnd{Exch

Re: Testing hotspot's Atomic::cmpxchg(jbyte*) ?

On 08/19/2016 10:13 AM, David Holmes wrote: >> Now it might be cleaner to ditch Java version from Unsafe, and make >> native entry points like Unsafe_CompareAnd{Exchange,Swap}{Byte,Short} >> which would call relevant Atomic::cmpxchg-s. > > I tried commenting out the Java-ish version and defining

Re: Testing hotspot's Atomic::cmpxchg(jbyte*) ?

On 08/19/2016 08:15 AM, David Holmes wrote: > I need to test the jbyte version of Atomic::cmpxchg in the VM, but so > far it doesn't seem to be the case that any library code will actually > invoke it. At the top Java level there is no AtomicByte class. Unsafe > defines compareAndSwapByte variants

Re: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle

On 08/18/2016 05:32 PM, Claes Redestad wrote: > http://cr.openjdk.java.net/~redestad/8164044/webrev.03/ Doing this twice now? +dedupSet.add(methodTypes[i]); Otherwise thumbs up. -Aleksey

Re: [jdk9] RFR: 8163517: Various cleanup in java.io code

On 08/16/2016 08:20 PM, Ivan Gerasimov wrote: > Here is the updated webrev: > http://cr.openjdk.java.net/~igerasim/8163517/01/webrev/ Looks good to me. -Aleksey

Re: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle

On 08/18/2016 12:33 AM, Claes Redestad wrote: > Hi, > > please review this change which adds pre-generation of simple > DelegatingMethodHandles corresponding to the DirectMethodHandles we > already pre-generate during linking. > > webrev: http://cr.openjdk.java.net/~redestad/8164044/webrev.02/

Re: [jdk9] RFR: 8163517: Various cleanup in java.io code

On 08/16/2016 03:53 PM, Ivan Gerasimov wrote: > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163517 > WEBREV: http://cr.openjdk.java.net/~igerasim/8163517/00/webrev/ Both ObjectInputStream and ObjectOutputStream can use auto-unboxing in these blocks? 1271 if (result.booleanValue())

Re: RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access

On 08/15/2016 08:59 PM, Andrew Haley wrote: > On 15/08/16 18:40, Aleksey Shipilev wrote: >> On 08/15/2016 08:15 PM, Andrew Haley wrote: >>> has anyone looked at this yet? I've just got back from my travels. >> >> I think it was reviewed and committed, as "

Re: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions

On 08/15/2016 08:38 PM, Aleks Efimov wrote: > This problem was already fixed in Apache Xerces project [2] and I > would like to backport it to JDK9 Xerces implementation. Webrev with > the changes: http://cr.openjdk.java.net/~aefimov/8146961/9/00 Ouch. Looks good. Thanks, -Aleksey

Re: RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access

On 08/15/2016 08:15 PM, Andrew Haley wrote: > has anyone looked at this yet? I've just got back from my travels. I think it was reviewed and committed, as "HG Updater" comments say: https://bugs.openjdk.java.net/browse/JDK-8162458 Thanks, -Aleksey

Re: RFR: 8161016: Strange behavior of URLConnection with proxy

On 08/12/2016 10:56 PM, Ramanand Patil wrote: > Here is the updated Webrev: > http://cr.openjdk.java.net/~rpatil/8161016/webrev.01/ I think my version (below) is a little more straightforward, but no pressure. Your version is okay too, and does the minimal change. Thumbs up. Thanks, -Aleksey >

Re: RFR: 8163946: java/lang/String/concat/WithSecurityManager.java fails after 8163878

On 08/12/2016 03:55 PM, Claes Redestad wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8163946 > webrev: http://cr.openjdk.java.net/~redestad/8163946/webrev.01/ +1. Welcome to our world (of pain). Please run java/lang/String tests next time anything changes in StringConcatFactory?

Re: RFR: 8163878: Remove unnecessary bridge methods, allocations in java.lang.invoke

On 08/11/2016 11:51 PM, Michael Haupt wrote: > thumbs up - I'd appreciate if Aleksey could take a glance at the changes in > the String concatenation logic though. > > Best, > Michael > >> Am 11.08.2016 um 10:55 schrieb Claes Redestad : >> >> while further untangling

Re: RFR: jsr166 jdk9 integration wave 9

On 08/11/2016 11:56 PM, Martin Buchholz wrote: > I can imagine a machine that has a native cas instruction, but no native > exchange instruction, but no one ever got fired for optimizing for x86. ...which would be less of an issue once we switch to proper-boolean VarHandles, not the

Re: RFR: jsr166 jdk9 integration wave 9

On 08/11/2016 09:59 PM, Martin Buchholz wrote: > On Thu, Aug 11, 2016 at 10:40 AM, Aleksey Shipilev >> Why doesn't AtomicBoolean.getAndSet use VarHandle.getAndSet, which is >> hopefully intrinsified completely? > > Good question. This optimization originated in a suggest

Re: RFR: jsr166 jdk9 integration wave 9

On 08/11/2016 04:34 AM, Martin Buchholz wrote: > Again, no spec changes, but larger than expected. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ Why doesn't AtomicBoolean.getAndSet use VarHandle.getAndSet, which is hopefully intrinsified completely? I like the

Re: RFR: 8161016: Strange behavior of URLConnection with proxy

On 08/11/2016 05:17 PM, Ramanand Patil wrote: > Webrev: http://cr.openjdk.java.net/~rpatil/8161016/webrev.00/ > > Fix: Instead of falling back to direct connection when last proxy > fails to open connection, re-try once with the last proxy. An > alternate solution can also be- don't try to open

Re: [9] RFR 8163518: Integer overflow in StringBufferInputStream.read(byte[], int, int) and CharArrayReader.read(char[], int, int)

Yes, looks good. Thanks, -Aleksey On Thu, Aug 11, 2016 at 2:20 AM, Ivan Gerasimov wrote: > Okay, I simplified that confusing part of the fix and made a minimal > change to minimize chances of any unintended changes in behavior. > >

Re: [9] RFR 8163518: Integer overflow in StringBufferInputStream.read(byte[], int, int) and CharArrayReader.read(char[], int, int)

On 08/10/2016 10:40 PM, Aleksey Shipilev wrote: > On 08/10/2016 08:55 PM, Ivan Gerasimov wrote: >> http://cr.openjdk.java.net/~igerasim/8163518/01/webrev/ >> >> Would you please help review it once again? > > I wonder, shouldn't it be (n <= k) here: > >

Re: [9] RFR 8163518: Integer overflow in StringBufferInputStream.read(byte[], int, int) and CharArrayReader.read(char[], int, int)

On 08/10/2016 08:55 PM, Ivan Gerasimov wrote: > http://cr.openjdk.java.net/~igerasim/8163518/01/webrev/ > > Would you please help review it once again? I wonder, shouldn't it be (n <= k) here: 164 long k = count - pos; 165 if (n < k) { 166 k = (n <= 0)

Re: RFR 8161444 VarHandles should provide access bitwise atomics

On 08/10/2016 03:14 AM, Paul Sandoz wrote: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8161444-vhs-bitwise-atomics/webrev/ *) I probably missed this discussion, but why do we have bitwise ops on boolean? I don't think boolean is a integral type to have exposed bit representation. (Edit:

Re: RFR 8162106 Remove VarHandle.addAndGet

On 08/10/2016 05:37 PM, Paul Sandoz wrote: > Please review the following webrev which removes > VarHandle.addAndGet: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162106-vhs-rm-addAndGet/webrev/ The removal looks good. +1 from me. > The previous incarnation of those tests was awkwardly

Re: RFR: 8163370: Reduce number of classes loaded by common usage of java.lang.invoke

On 08/10/2016 06:20 PM, Claes Redestad wrote: > On 2016-08-10 17:07, Aleksey Shipilev wrote: >> On 08/09/2016 03:04 PM, Claes Redestad wrote: >>> please review this set of small changes to reduce the number of classes >>> defined and pulled in when initializing java

Re: [9] RFR 8163518: Integer overflow in StringBufferInputStream.read(byte[], int, int) and CharArrayReader.read(char[], int, int)

On 08/10/2016 03:12 AM, Ivan Gerasimov wrote: > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163518 > WEBREV: http://cr.openjdk.java.net/~igerasim/8163518/00/webrev/ Looks good to me. Thanks, -Aleksey

Re: RFR: 8163370: Reduce number of classes loaded by common usage of java.lang.invoke

On 08/09/2016 03:04 PM, Claes Redestad wrote: > please review this set of small changes to reduce the number of classes > defined and pulled in when initializing java.lang.invoke > > Webrev: http://cr.openjdk.java.net/~redestad/8163370/webrev/ > Bug:

Re: Collectors.toSet() small performance improvement

On 08/09/2016 10:19 AM, Tagir F. Valeev wrote: > AS> Good trick, but does it work properly with the sets that care about the > AS> add order, e.g. LinkedHashSet? I guess our saving grace here is > AS> Collector.toSet() is declared UNORDERED, so we can disturb the encounter > AS> order without

Re: Collectors.toSet() small performance improvement

On 08/09/2016 08:31 AM, Tagir F. Valeev wrote: > --- a/src/java.base/share/classes/java/util/stream/Collectors.java Tue > Aug 02 07:19:06 2016 +0530 > +++ b/src/java.base/share/classes/java/util/stream/Collectors.java Tue > Aug 09 11:47:20 2016 +0700 > @@ -295,7 +295,12 @@ >

Re: RFR (XS): 8162815: unnecessary object creation in reflection

On 08/09/2016 12:09 AM, Paul Sandoz wrote: >> On 4 Aug 2016, at 12:02, Claes Redestad >> wrote: >> Hi, >> >> I'd like to sponsor this bug fix provided by Tomáš Hůrka to remove >> a new and dup left behind in generated accessor methods after >> moving these to use

Re: RFR: 8163369: Enable generating DMH classes at link time

On 08/08/2016 04:18 PM, Claes Redestad wrote: > http://cr.openjdk.java.net/~redestad/8163369/webrev.02/ Looks good. -Aleksey

Re: RFR: 8163369: Enable generating DMH classes at link time

On 08/08/2016 02:46 PM, Claes Redestad wrote: > Hi, > > please review this change to add the ability to generate > DirectMethodHandles to the --generate-jli-classes jlink plugin. > > The implementation generates all the specified DMHs as methods into a > single class,

Re: RFR: 8161379: Force inline methods calling Reflection.getCallerClass

On 08/05/2016 11:22 PM, Claes Redestad wrote: > On 08/05/2016 12:56 PM, Aleksey Shipilev wrote: >> I wouldn't mind to have a comment at @ForceInline line mentioning this >> is for Reflection.getCallerClass() optimization. But, it might be >> recoverable from the source cont

Re: RFR: 8161379: Force inline methods calling Reflection.getCallerClass

This looks good to me, Claes. I wouldn't mind to have a comment at @ForceInline line mentioning this is for Reflection.getCallerClass() optimization. But, it might be recoverable from the source control anyway. Thanks, -Aleksey On 08/05/2016 10:37 PM, Claes Redestad wrote: > Anyone? > > On

Re: RFR [9] 8154017: Shutdown hooks are racing against shutdown sequence, if System.exit()-calling thread is interrupted

On 23.06.2016 19:32, Chris Hegarty wrote: > The shutdown hooks race against the shutdown sequence if the thread > invoking System.exit() is interrupted. This happens because > ApplicationShutdownHooks::runHooks joins the shutdown hooks. This > may lead to premature VM shutdown, with shutdown

Re: RFR 8154737: Rename VarHandle.compareAndExchangeVolatile to VarHandle.compareAndExchange

On 06/22/2016 12:34 PM, Paul Sandoz wrote: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154737-vh-cae-volatile-rename/webrev/ +1 -Aleksey

Re: [jdk9] RFR: 8159822: Non-synchronized access to shared members of com.sun.jndi.ldap.pool.Pool

On 06/21/2016 06:14 PM, Ivan Gerasimov wrote: > Hello! > > The Pool has a member `map`, which is accessed from different threads, > thus the access is synchronized. > However, in some code paths (mostly in debug printing) it is accessed > without proper synchronization, which results in

Re: RFR: 8158933: String concat stringifiers setup should avoid unnecessary lookups

On 06/07/2016 06:15 PM, Claes Redestad wrote: > By restructuring this code we can optimize the number of lookups made, > slightly improving startup. > > Webrev: http://cr.openjdk.java.net/~redestad/8158933/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8158933 Looks good. Are the

Re: JDK 9 RFR of JDK-8154980: Remove intermittent key from test BandIntegrity.java

On 05/30/2016 10:33 AM, Amy Lu wrote: > tools/pack200/BandIntegrity.java > > This test was failing intermittently (JDK-8154049). Mentioned issues > have been resolved and no open bug (no failure reported) till now. > > This patch is to remove @key intermittent from the test. > > bug:

Re: JDK 9 RFR of JDK-6961865: javadoc for Boolean.valueOf(String) with null argument not clearly specified

On 05/26/2016 10:02 PM, joe darcy wrote: > JDK-6961865: javadoc for Boolean.valueOf(String) with null argument > not clearly specified > > http://cr.openjdk.java.net/~darcy/6961865.0/ +1 Thanks, -Aleksey

Re: RFR [9] 8157825: Remove JDK 9 specific methods from sun.misc.Unsafe

On 05/25/2016 01:43 PM, Chris Hegarty wrote: > sun.misc.Unsafe, in the jdk.unsupported module, should not have any new > public > methods that were not already part of its API in JDK 8. This issue will > remove three > such methods, getUncompressedObject, getJavaMirror, and getKlassPointer,

Re: JDK 9 RFR of JDK-8157813: Remove sun/rmi/transport/proxy/EagerHttpFallback.java from ProblemList.txt

On 05/25/2016 12:44 PM, Amy Lu wrote: > This patch is to remove this test from ProblemList.txt as well. > > bug: https://bugs.openjdk.java.net/browse/JDK-8157813 > webrev: http://cr.openjdk.java.net/~amlu/8157813/webrev.00/ Reviewed. Thanks, -Aleksey

Re: 8157677: Subclasses of Reader do not inherit the contents in the exception tag from the parent Reader class in the latest spec

On 05/24/2016 05:24 PM, Pavel Rappo wrote: > Thanks for looking at this! > >> On 24 May 2016, at 15:16, Aleksey Shipilev <aleksey.shipi...@oracle.com> >> wrote: >> >> *) CharArrayReader: code changes > > What's your concern with 'b'->'buf' rename?

Re: VarHandles on non-int-sized fields and atomic operations

On 05/24/2016 05:43 AM, John Rose wrote: > On May 23, 2016, at 4:20 PM, Martin Buchholz > wrote: >> >> As I said in a previous message, you can implement subword CAS using >> fullword CAS in a loop. >> >> cas8bit(expect, update) { >> for (;;) {

Re: 8157677: Subclasses of Reader do not inherit the contents in the exception tag from the parent Reader class in the latest spec

On 05/24/2016 05:08 PM, Pavel Rappo wrote: > Could you please review a trivial change for JDK-8157677? > >http://cr.openjdk.java.net/~prappo/8157677/webrev.00/ *) CharArrayReader: code changes *) It's weird to see @exception and @throws side-by-side: * @exception IOException If

Re: VarHandles on non-int-sized fields and atomic operations

On 05/24/2016 01:32 AM, Martin Buchholz wrote: > On Mon, May 23, 2016 at 3:15 PM, Aleksey Shipilev > <aleksey.shipi...@oracle.com> wrote: >>> Since atomic fields need different field layout from regular fields, >>> it seems to make sense to require that fields

Re: RFR: JDK-8153768 Miscellaneous changes imported from jsr166 CVS 2016-05

On 05/23/2016 11:32 PM, Martin Buchholz wrote: > JSR166 CVS has some unfinished work in progress, but enough minor > changes have accumulated that we should integrate into openjdk9: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/ *) Removing

Re: VarHandles on non-int-sized fields and atomic operations

On 05/23/2016 11:16 PM, Martin Buchholz wrote: > With VarHandles, the declared fields are Ordinary Java Fields, so they > are likely to be layed out as with normal fields. > As a result, it looks like you can't do a cas with a VarHandle to a > short field. > If that's true, then the hardware is

Re: RFR: 8157449: Adjust link-time generated Species classes to match JDK-8148604 usage

On 05/20/2016 05:16 PM, Claes Redestad wrote: > Webrev: http://cr.openjdk.java.net/~redestad/8157449/webrev.00/ Looks good. Thanks, -Aleksey

Re: RFR: 8157437 Typos in Stream JavaDoc

Looks good. Thanks, -Aleksey On 05/20/2016 02:47 PM, Paul Sandoz wrote: > Hi, > > I introduced some typos in my haste to push the fix for JDK-8130023 > (API java.util.stream: explicitly specify guaranteed execution of the > pipeline) (I am reminded of the phrase “Go slow and you’ll get

Re: RFR (M) 8148604: JEP 280, Switch to more optimal concatenation strategy

experiments, but that will > help us pinpoint areas to focus startup optimization efforts on going > forward. > > Thanks! > > /Claes > > On 2016-05-18 14:09, Aleksey Shipilev wrote: >> Hi, >> >> We have been waiting for this for at least 8 weeks, waiti

Re: RFR: 8156807: Pack200 must support v53.0 class files

On 05/18/2016 05:20 PM, Kumar Srinivasan wrote: > The second part is fixing up the test, which does not read the > process streams correctly and causes a test hang, simplified > the test with time tested utilities. > > http://cr.openjdk.java.net/~ksrini/8156807/webrev.00/ A very minor snag in

RFR (M) 8148604: JEP 280, Switch to more optimal concatenation strategy

Hi, We have been waiting for this for at least 8 weeks, waiting for Jigsaw to settle in, and hs-main -> jdk9/dev integration to happen that brings a few testbug fixes into the jdk9/dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8148604 Webrev:

Re: RFR 8157152: Atomic add for VarHandle byte[]/ByteBuffer views is incorrect for endian conversion

On 05/18/2016 02:24 PM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8157152-vh-array-views-atomic-add-endianness/webrev/ Looks horrible (as many other endianness fixes), but correct. Reviewed. Thanks, -Aleksey

Re: RFR (S) 8157171: Hook up Unsafe.weakCompareAndSetVolatile to VarHandles

Thanks Paul and Claes, pushed. -Aleksey On 05/17/2016 10:16 PM, Claes Redestad wrote: > +1 > > On 2016-05-17 18:46, Aleksey Shipilev wrote: >> Hi, >> >> Now that jdk9/hs merged to jdk9/dev, we can finally make a move to >> connect new Unsafe.weakCompareAndSetVo

Re: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode

On 05/17/2016 07:50 PM, shilpi.rast...@oracle.com wrote: > On 5/17/2016 7:44 PM, Alan Bateman wrote: >> >> On 17/05/2016 14:34, Martin Buchholz wrote: >>> In jdk8 the /othervm is missing. >>> http://mail.openjdk.java.net/pipermail/jtreg-use/2016-May/000478.html >>> >> Ah, I assumed we were

RFR (S) 8157171: Hook up Unsafe.weakCompareAndSetVolatile to VarHandles

Hi, Now that jdk9/hs merged to jdk9/dev, we can finally make a move to connect new Unsafe.weakCompareAndSetVolatile intrinsics with VarHandles: https://bugs.openjdk.java.net/browse/JDK-8157171 Webrev: http://cr.openjdk.java.net/~shade/8157171/webrev.01/ The core changes are in the template

Re: RFR 8157146: Add debug printlns to tests FieldSetAccessibleTest and VerifyJimage.java

On 05/17/2016 04:26 PM, Sundararajan Athijegannathan wrote: > Please review the updated webrev: > http://cr.openjdk.java.net/~sundar/8157146/webrev.01/ Yes, reviewed. Thanks, -Aleksey

Re: RFR 8157146: Add debug printlns to tests FieldSetAccessibleTest and VerifyJimage.java

On 05/17/2016 03:54 PM, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8157146/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8157146 Shouldn't it follow the same pattern other catch blocks? Surely you want to run all test cases, and not abort on

Re: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode

On 05/17/2016 03:45 PM, shilpi.rast...@oracle.com wrote: > On 5/17/2016 6:00 PM, Aleksey Shipilev wrote: >> On 05/17/2016 03:21 PM, shilpi.rast...@oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8155791 >>> http://cr.openjdk.java.net/~srastogi/815

Re: RFR [9]: 8157096: [TEST_BUG] test/javax/xml/bind/xjc/8145039/JaxbMarshallTest.java is skipped by jtreg

On 05/17/2016 02:57 AM, Aleks Efimov wrote: > Webrev: http://cr.openjdk.java.net/~aefimov/8157096/9/00 > JBS: https://bugs.openjdk.java.net/browse/JDK-8157096 Looks good. Thanks, -Aleksey

Re: RFR[9]:java/lang/invoke/VarargsArrayTest.java miss othervm for main/bootclasspath mode

On 05/17/2016 03:21 PM, shilpi.rast...@oracle.com wrote: > Gentle Reminder! > > https://bugs.openjdk.java.net/browse/JDK-8155791 > http://cr.openjdk.java.net/~srastogi/8155791/webrev.00/ >>> Parse Exception: [-esa]: vm option(s) found, need to specify /othervm Still not getting this. The

Re: RFR: JDK-8150496,(zipfs) Fix performance issues in zip-fs

On 05/04/2016 10:14 PM, Xueming Shen wrote: > http://cr.openjdk.java.net/~sherman/8150496/webrev Okay, good. > yes, the performance gains still hold. > > Benchmark Mode Cnt Score Error Units >

Re: RFR: JDK-8150496,(zipfs) Fix performance issues in zip-fs

Hi Sherman, On 05/03/2016 11:19 PM, Xueming Shen wrote: > Again, thanks for the review. The webrev has been updated accordingly, > as well as the MyBenchmark.java (to use Blackhole, as suggested) > > http://cr.openjdk.java.net/~sherman/8150496/webrev/ Further nits, sorry for not catching them

Re: RFR 8154049: DualPivot sorting calculates incorrect runs for nearly sorted arrays

On 04/21/2016 04:24 PM, Paul Sandoz wrote: > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154049-dual-pivot-sort-one-off-error/webrev/ Ew. It is a complete brain-twister to understand the original code, the original improvement, the bug, and the fix -- all four! This is a

Re: RFR 8155258: VarHandle implementation improvements

On 05/03/2016 09:35 PM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-jdk/webrev/ > Okay then, looks good. -Aleksey

Re: RFR 8155258: VarHandle implementation improvements

On 05/03/2016 01:18 AM, Paul Sandoz wrote: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-jdk/webrev/ > > > >

<    1   2   3   4   5   6   7   8   9   10   >