Re: RFR: 8237878: Improve ModuleLoaderMap datastructures

Hi Claes, I hope I'm not to late to comment on this. This change is ok as it stands, but I'm afraid it is not in the spirit of Valhalla. As I understand, you rely on the fact that Integer instances in the low range of values are cached and you then use identity comparison in the following met

Re: [PATCH] Enhancement proposal for java.util.StringJoiner

Hello, I've reworked the patch in order to decide about char[] / byte[] lazily. This allows to dodge performance impact of reflective calls to String.isLatin1() for non-latin Strings and at the same time keep the benefits of discrimination between char[] / byte[]. I've collected resutls for a

Re: RFR: 8237878: Improve ModuleLoaderMap datastructures

Hi, On 2020-02-13 09:12, Peter Levart wrote: This change is ok as it stands, but I'm afraid it is not in the spirit of Valhalla. I wouldn't really know what the spirit of Valhalla will end up being, yet. :-) Unboxing the values have a measurable cost in the interpreter, and can trigger some v

Re: JDK 15 RFR of JDK-8237805: Use inline @jls @jvms in core libs where appropriate

Hi Joe, Nits: http://cr.openjdk.java.net/~darcy/8237805.0/src/java.base/share/classes/java/lang/invoke/MethodHandle.java.frames.html line 226 http://cr.openjdk.java.net/~darcy/8237805.0/src/java.base/share/classes/java/lang/invoke/MethodHandleInfo.java.frames.html line 46 http://cr.openjdk.jav

Re: JDK 15 RFR of JDK-8237805: Use inline @jls @jvms in core libs where appropriate

@Joe, I noticed you changed "section" to the § entity in one place. In other places it is still in prose, i.e. "section" and "sections". I think whatever we choose we should try to use it consistently. I built the API docs and checked that everything renders as expected. (Links are 404, obviously,

Re: RFR: 8238773: Miscellaneous ODR violations in UNIX native code

On 2/10/20 4:44 PM, Andrew Haley wrote: > In a couple of places variables are defined in header files, leading > to violations of the One Definition Rule. This is not Standard C and > breaks the build on modern compilers which complain. > > http://cr.openjdk.java.net/~aph/8238773/ I withdraw this

Should indexOfLatin1Unsafe be private instead of public in java\lang\StringUTF16.java?

Hi, A quick question, I read the code snippets of indexOf(String str), found indexOfUnsafe [1] and indexOfLatin1Unsafe [2] have different access control, but it looks both should be private. Did I miss any outer caller or any other restriction? Thanks for your comment. [1] private static int i

Re: RFR: 8238953: tools/jpackage tests do not work on Ubuntu Linux

Hi Matthias, We don't set "jpackage.test.disabledPackagers" property from the test code. It is assumed to be set from jtreg command line that runs tests. The value of the property is just checked in tests. So basically there is no need to change code at all. However, if you want to disable run

Re: Should indexOfLatin1Unsafe be private instead of public in java\lang\StringUTF16.java?

Hi Patrick, Private would be good, but since they are in a package-private class they are not visibile outside the package. If there is some other change to the class then fix it but otherwise not worth the overhead. Roger On 2/13/20 10:34 AM, Patrick Zhang OS wrote: Hi, A quick question,

RFR(S) : 8238943: switch to jtreg 5.0

http://cr.openjdk.java.net/~iignatyev//8238943/webrev.00 > 10 lines changed: 1 ins; 0 del; 9 mod; Hi all, could you please review the patch which changes jtreg version used in jdk/jdk to the latest and greatest -- jtreg 5.0? and as (recently became) usually, this patch also bumps requiredVersio

Re: RFR(S) : 8238943: switch to jtreg 5.0

Igor, The change to langtools/TEST.ROOT is OK. That being said, there are some old entries there which could also be cleaned up (separately?)  These lines probably date from the development of JDK 9 and the evolution of Project Jigsaw. 20 # Use new module options 21 useNewOptions=true

Re: RFR(S) : 8238943: switch to jtreg 5.0

Looks good, but could you change the "version" field to "5.0", it should work now. /Erik On 2020-02-13 08:50, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8238943/webrev.00 10 lines changed: 1 ins; 0 del; 9 mod; Hi all, could you please review the patch which changes jtreg ve

RFR (XS) 8239007: java/math/BigInteger/largeMemory/ tests should be disabled on 32-bit platforms

Test bug: https://bugs.openjdk.java.net/browse/JDK-8239007 Fix: https://cr.openjdk.java.net/~shade/8239007/webrev.01/ Follows the precedent of: https://hg.openjdk.java.net/jdk/jdk/rev/848859723503 Testing: affected tests on Linux {x86_64, x86_32} -- Thanks, -Aleksey

Re: RFR(S) : 8238943: switch to jtreg 5.0

Oh, I’m sorry I actually changed it to 5.0 when were (re)doing testing, and apparently forgot to replace the webrev, the right is http://cr.openjdk.java.net/~iignatyev//8238943/webrev.01 ; with version field value being the only difference b/w .00 and .01 Thanks, — Igor > On Feb 13, 2020, at 9

Re: RFR (XS) 8239007: java/math/BigInteger/largeMemory/ tests should be disabled on 32-bit platforms

+1 Brian > On Feb 13, 2020, at 10:10 AM, Aleksey Shipilev wrote: > > Test bug: > https://bugs.openjdk.java.net/browse/JDK-8239007 > > > Fix: > https://cr.openjdk.java.net/~shade/8239007/webrev.01/ >

Re: RFR (XS) 8239007: java/math/BigInteger/largeMemory/ tests should be disabled on 32-bit platforms

Thanks. Trivial? On 2/13/20 7:12 PM, Brian Burkhalter wrote: > +1 > > Brian > >> On Feb 13, 2020, at 10:10 AM, Aleksey Shipilev > > wrote: >> >> Test bug: >>  https://bugs.openjdk.java.net/browse/JDK-8239007 >> >> Fix: >>  https://cr.openjdk.java.net/~shade/8239007/webre

Re: RFR (XS) 8239007: java/math/BigInteger/largeMemory/ tests should be disabled on 32-bit platforms

Works for me. Brian > On Feb 13, 2020, at 10:13 AM, Aleksey Shipilev wrote: > > Thanks. Trivial? > > On 2/13/20 7:12 PM, Brian Burkhalter wrote: >> +1 >> >> Brian >> >>> On Feb 13, 2020, at 10:10 AM, Aleksey Shipilev >> > wrote: >>> >>> Test bug: >>> https://bugs.o

Re: RFR(S) : 8238943: switch to jtreg 5.0

+1 for the change to test/jaxp/TEST.ROOT. Best, Joe On 2/13/20 10:08 AM, Igor Ignatev wrote: Oh, I’m sorry I actually changed it to 5.0 when were (re)doing testing, and apparently forgot to replace the webrev, the right is http://cr.openjdk.java.net/~iignatyev//8238943/webrev.01 ; with versi

Re: JDK 15 RFR of JDK-8237805: Use inline @jls @jvms in core libs where appropriate(Internet mail)

Hi Felix, Noted; I run a script before pushing to update the copyright year. Thanks, -Joe On 2/12/2020 9:28 PM, felixxfyang(杨晓峰) wrote: Hi Joe， A minor comment on copyright date 2019 -> 2020 -Felix 在 2020/2/13 下午12:49，“core-libs-dev 代表 Joe Darcy” 写入: Hello, Inline forms

Re: RFR (XS) 8239007: java/math/BigInteger/largeMemory/ tests should be disabled on 32-bit platforms

Good. Pushed. Cheers, -Aleksey On 2/13/20 7:14 PM, Brian Burkhalter wrote: > Works for me. > > Brian > >> On Feb 13, 2020, at 10:13 AM, Aleksey Shipilev wrote: >> >> Thanks. Trivial? >> >> On 2/13/20 7:12 PM, Brian Burkhalter wrote: >>> +1 >>> >>> Brian >>> On Feb 13, 2020, at 10:10 AM, A

Re: RFR(S) : 8238943: switch to jtreg 5.0

Looks good. /Erik On 2020-02-13 10:08, Igor Ignatev wrote: Oh, I’m sorry I actually changed it to 5.0 when were (re)doing testing, and apparently forgot to replace the webrev, the right is http://cr.openjdk.java.net/~iignatyev//8238943/webrev.01 ; with version field value being the only diff

Re: JDK 15 RFR of JDK-8237805: Use inline @jls @jvms in core libs where appropriate

Hello, I changed the one "§" to "section" and re-flowed the paragraphs with long lines. I believe the existing use of     (Lorem ipsum ... aliqua.) is correct rather than     (Lorem ipsum ... aliqua). Thanks, -Joe On 2/13/2020 3:14 AM, Pavel Rappo wrote: @Joe, I noticed you changed "sec

Re: [PATCH] Enhancement proposal for java.util.StringJoiner

As a point of interest, some investigation of updating StringJoiner for CompactStrings was done a while back. See https://bugs.openjdk.java.net/browse/JDK-8148937 -Brent On 2/3/20 2:38 PM, Сергей Цыпанов wrote: Hello, as of JDK14 java.util.StringJoiner still uses char[] as a storage of glued

RE: Should indexOfLatin1Unsafe be private instead of public in java\lang\StringUTF16.java?

OK, thanks Roger, I am looking for the opportunity of speeding up indexOf, and would fix it by the way once I have a patch there. Regards Patrick -Original Message- From: core-libs-dev On Behalf Of Roger Riggs Sent: Friday, February 14, 2020 12:12 AM To: core-libs-dev@openjdk.java.net

RFR 8238579: HttpsURLConnection drops the timeout and hangs forever in read

Hi All, Please find the below fix which resolves the issue( https://bugs.openjdk.java.net/browse/JDK-8238579). "HttpURLConnection.writeRequests()" retry in case of any write failure, during retry it creates new HttpsClient without connectTimeout & readTimeout. Below fix sets the connect & read

Re: RFR 8238579: HttpsURLConnection drops the timeout and hangs forever in read(Internet mail)

Hi Vyom, The patch looks fine. Can you add a regression test for it? Thanks, Felix Yang 在 2020/2/14 下午1:01，“core-libs-dev 代表 Vyom Tiwari” 写入: Hi All, Please find the below fix which resolves the issue( https://bugs.openjdk.java.net/browse/JDK-8238579). "HttpURLConne

Re: [PATCH] Enhancement proposal for java.util.StringJoiner

Oh, I was unaware of it! Thanks! 13.02.2020, 21:49, "Brent Christian" : > As a point of interest, some investigation of updating StringJoiner for > CompactStrings was done a while back. > > See https://bugs.openjdk.java.net/browse/JDK-8148937 > > -Brent > > On 2/3/20 2:38 PM, Сергей Цыпанов wrote: