Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

David, Thanks! On Wed, Feb 7, 2018 at 7:32 PM, David Holmes wrote: > Moving to core-libs-dev. Code reviews don't take place on jdk-dev but on > the component area mailing lists. > > Thanks, > David > > > On 8/02/2018 6:10 AM, yumin qi wrote: > >> Hi, >> >>Please

Re: RFR JDK-8164278: java.util.Base64.EncOutputStream/DecInputStream is slower than corresponding version in javax.mail package

Hi Roger, Given the concern of the possible incompatible behavior change of over reading bytes from the underlying stream. I decided to give up last proposed changes for DecInputStream for now. With some "minor" cleanup and tuning I still have about 10%+ improvement with various input size

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

Moving to core-libs-dev. Code reviews don't take place on jdk-dev but on the component area mailing lists. Thanks, David On 8/02/2018 6:10 AM, yumin qi wrote: Hi, Please review the fix (extra small) for: bug 8194154: https://bugs.openjdk.java.net/browse/JDK-8194154 webrev:

Re: RFR: 8041626: [Event Request] Shutdown reason

Hi Robin, Adding in hotspot-runtime-dev as all the hotspot changes belong to runtime. I had an initial look through this. To be honest I don't like it. We seem to have to record little bits of information all over the place just so they can be reported by the shutdown event. It seems untidy.

Re: JDK 11 RFR of JDK-8196995: java.lang.Character should not state UTF-16 encoding is used for strings

I'm not sure about this. The LATIN-1 optimization is an implementation detail. The important thing is the API, and it remains char-oriented (although we've added codepoint APIs over the years). Strictly speaking, you can store any 16-bit integer sequences in char[], String, or StringBuffer - no

Re: RFR: 8196869: Optimize Locale creation

This is looking much better, definitely easier to understand. Paul. > On Feb 7, 2018, at 4:38 PM, Claes Redestad wrote: > > Hi, > > On 2018-02-07 15:23, Claes Redestad wrote: >> - use map.replace to safely update the entry when putIfAbsent returns an >> object >>

Re: RFR [11] (JAXP): 6857903: SAXException.initCause() does not correctly set Exception

Hi Jason, Roger, Thanks for your comments. The new webrev with suggested/recommended edits can be viewed at this location: http://cr.openjdk.java.net/~aefimov/6857903/dev/03/ Thanks, Aleksei PS: Also configured my IDE to use explicit imports =) On 02/06/2018 03:31 PM, Roger Riggs wrote: Hi

Re: RFR: 8196869: Optimize Locale creation

Hi, On 2018-02-07 15:23, Claes Redestad wrote: - use map.replace to safely update the entry when putIfAbsent returns an object   but it points to a cleared value, so that (benign) races to create new Locale objects   will canonicalize turns out the implementation attempted here with

Re: RFR 8190378: Java EE and CORBA modules removal

Hi Mandy > On Feb 7, 2018, at 5:00 PM, mandy chung wrote: > > Hi Lance, > > Great to see this JEP moving along. I reviewed all changes except > test/langtools/tools/javac tests. > > Looks fine overall. Thank you for the review. > Minor comments: > >

JDK 11 RFR of JDK-8196995: java.lang.Character should not state UTF-16 encoding is used for strings

Hello, Text in java.lang.Character states a UTF-16 character encoding is used for java.lang.String. While was true for many years, it is not necessarily true and not true in practice as of JDK 9 due to the improvements from JEP 254: Compact Strings. The statement about the encoding should

Re: RFR 8190378: Java EE and CORBA modules removal

Hi Lance, Great to see this JEP moving along. I reviewed all changes except test/langtools/tools/javac tests. Looks fine overall. Minor comments: src/java.base/share/lib/security/default.policy - no change in this file. test/jdk/tools/jmod/hashes/HashesTest.java

Re: RFR 8190378: Java EE and CORBA modules removal

Hi Goetz, I updated the webrev with the suggested update http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/test/jdk/tools/launcher/HelpFlagsTest.java.sdiff.html Best Lance > On Feb 7, 2018, at 3:20 PM, Lindenmaier, Goetz > wrote: > > Hi Lance, >

Re: RFR: 8041626: [Event Request] Shutdown reason

Hi Alan, > On 7 Feb 2018, at 16:30, Alan Bateman wrote: > > On 07/02/2018 15:18, Robin Westberg wrote: >> Hi all, >> >> Please review the following change that adds an event-based tracing event >> that is generated when the VM shuts down. The intent is to capture

Re: RFR: 8041626: [Event Request] Shutdown reason

Hi Robin, I can sponsor this. I wonder if we should change the name of the event to "Shutdown" instead? It will give us flexibility to add other shutdown related fields in the future. Could you change the label and field to "Status Code" and statusCode. Event fields should have

RE: RFR 8190378: Java EE and CORBA modules removal

Hi Lance, Would you mind to add similar change as for test/jdk/tools/launcher/VersionCheck.java also for test/jdk/tools/launcher/HelpFlagsTest.java That test is pretty recent which is why you may have missed it. It will not fail though, there will just be left over stuff in it. Best regards,

RFR : 8196854 :TestFlushableGZIPOutputStream failing with IndexOutOfBoundsException

A jdk8u (and earlier) issue where some new/recent test code meant that IndexOutOfBoundsException could be thrown. https://bugs.openjdk.java.net/browse/JDK-8196854 http://cr.openjdk.java.net/~coffeys/webrev.8196854/webrev/ The buf array was never required and I've verified that the original

Re: RFR 8196298 Add null Reader and Writer

> Am 07.02.2018 um 14:03 schrieb Alan Bateman : > > On 03/02/2018 17:05, Patrick Reinhart wrote: >> : >> I reworked the tests and Writer implementation accordingly >> >> http://cr.openjdk.java.net/~reinhapa/reviews/8196298/webrev.01 >> > Just catching up on this. > >

Re: RFR 8190378: Java EE and CORBA modules removal

Build changes look good. /Erik On 2018-02-07 08:57, Lance Andersen wrote: Hi all, I think we are at a point where we are ready to start reviewing the changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, has been targeted to JDK 11. The CSR for removing the modules

RFR 8190378: Java EE and CORBA modules removal

Hi all, I think we are at a point where we are ready to start reviewing the changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, has been targeted to JDK 11. The CSR for removing the modules has been approved: https://bugs.openjdk.java.net/browse/JDK-8193757

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Vladimir, just to be sure I presume your analysis applies to both C1 and C2? what about compilers such as Graal? I only looked at C1 & C2, but I'm sure it applies to Graal as well: GC interaction mechanism is the same for all JIT-compilers in HotSpot. Best regards, Vladimir Ivanov

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

> On Feb 7, 2018, at 7:22 AM, Vladimir Ivanov > wrote: > > Peter, > >>> Objects.requireNonNull() shows zero overhead here. >>> >>> I guess the main question is whether Objects.requireNonNull(this) behavior >>> in the former test is a result of chance and

Re: RFR: 8041626: [Event Request] Shutdown reason

On 07/02/2018 15:18, Robin Westberg wrote: Hi all, Please review the following change that adds an event-based tracing event that is generated when the VM shuts down. The intent is to capture shutdowns that occur after the VM has been properly initialized (as initialization problems would

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Peter, Objects.requireNonNull() shows zero overhead here. I guess the main question is whether Objects.requireNonNull(this) behavior in the former test is a result of chance and current Hotspot behavior or is it somehow guaranteed by the spec. I haven't looked into what actually happens

RFR: 8041626: [Event Request] Shutdown reason

Hi all, Please review the following change that adds an event-based tracing event that is generated when the VM shuts down. The intent is to capture shutdowns that occur after the VM has been properly initialized (as initialization problems would most likely mean that the tracing framework

Re: RFR: 8196869: Optimize Locale creation

On 2018-02-07 16:01, Peter Levart wrote: Hi Claes, On 02/07/2018 03:23 PM, Claes Redestad wrote: Updated webrev: http://cr.openjdk.java.net/~redestad/8196869/jdk.02/ - use map.remove(entry.getKey(), entry) instead of map.remove(entry.getKey()) - for most Locales, Locale$LocaleKey.exts is

Re: RFR: 8196869: Optimize Locale creation

Hi Claes, On 02/07/2018 03:23 PM, Claes Redestad wrote: Updated webrev: http://cr.openjdk.java.net/~redestad/8196869/jdk.02/ - use map.remove(entry.getKey(), entry) instead of map.remove(entry.getKey()) - for most Locales, Locale$LocaleKey.exts is null, so using the BaseLocale as key  

Re: RFR: 8196869: Optimize Locale creation

Hi, On 2018-02-07 13:55, Peter Levart wrote: Would making CacheEntry extend jdk.internal.ref.SoftCleanable instead of SoftReference help here? You could remove the cleanStaleEntries method entirely and just remove the Map entry in SoftCleanable's performCleanup method. possible, but

[PATCH] ObjectInputStream Reading Performance Optimisation

As per the guidance here - http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-February/003772.html , I am resubmitting this patch to this mailing list ... The main advantage of this optimisation is that a suitably "aware" compiler can avoid stack walking by using a private method named

Re: RFR 8196298 Add null Reader and Writer

On 03/02/2018 17:05, Patrick Reinhart wrote: : I reworked the tests and Writer implementation accordingly http://cr.openjdk.java.net/~reinhapa/reviews/8196298/webrev.01 Just catching up on this. nullReader's javadoc suggests that mark(int) does not nothing but this seems to conflict with

Re: RFR: 8196869: Optimize Locale creation

Hi Claes, On 02/07/2018 01:48 PM, Claes Redestad wrote: Hi, On 2018-02-07 13:12, Peter Levart wrote: Hi Claes, I studied the code briefly and understand why BaseLocale.Key now has to hold a SoftReference to a BaseLocale object when the same object is also part of CacheEntry which is also a

Re: RFR: 8196869: Optimize Locale creation

Hi, On 2018-02-07 13:12, Peter Levart wrote: Hi Claes, I studied the code briefly and understand why BaseLocale.Key now has to hold a SoftReference to a BaseLocale object when the same object is also part of CacheEntry which is also a SoftReference. But I don't see a reason why pre-patch

Re: RFR: 8196869: Optimize Locale creation

Hi Claes, Maybe I was to quick with my clicking on Send button... If the Key simply held strong references to individual String attributes, LocaleObjectCache.cleanStaleEntries would also have to be modified to make sure it does not remove valid entries that happen to share equal Key(s) with

Re: RFR: 8196869: Optimize Locale creation

Hi Claes, I studied the code briefly and understand why BaseLocale.Key now has to hold a SoftReference to a BaseLocale object when the same object is also part of CacheEntry which is also a SoftReference. But I don't see a reason why pre-patch BaseLocale.Key had to hold SoftReference(s) to

Re: RFR: 8196869: Optimize Locale creation

Hi Paul, On 2018-02-06 20:55, Paul Sandoz wrote: Quick observation: 261 private BaseLocale getBaseLocale() { 262 return (holder == null) ? holderRef.get() : holder; 263 } This method can return null if the soft ref has been cleared. But you don’t check in