Re: [JSR] [JEP] Java Specification Requirement / Java Enhancement Proposal : 'Parallel OR' and 'Parallel AND'

Hi Prakhar, The bar for getting new language features added is extremely high - new operators even higher I think. New operators for parallelism ... well I don't see that ever happening. I'm not a fan of implicit parallelism like you propose, it simply raises too many issues for the system t

Fwd: Re: Verify error in hg:jdk/jdk -- repository now READ-ONLY

FYI open again --- Begin Message --- Hi. hg:jdk/jdk is now open and verifies. Even if your local repository is corrupt, you may continue using it. The corruption does not propagate via pushes, since changeset IDs are unchanged. I strongly advise everybody to at least understand whether their l

Re: [14] RFR: 8212970: TZ database in "vanguard" format support

Thanks Naoto.  Looks good. -Joe On 7/24/19 3:24 PM, naoto.s...@oracle.com wrote: Hi Joe, Thank you for the review. On 7/24/19 2:57 PM, Joe Wang wrote: Hi Naoto, The method findNegativeSavings method in TzdbZoneRulesProvider.java states that it "Find the minimum negative savings". While the

Fwd: Verify error in hg:jdk/jdk -- repository now READ-ONLY

FYI in case this was not seen on jdk-dev list. David --- Begin Message --- Hi. I've made the hg:jdk/jdk repository READ-ONLY. A verify error which was discovered in the repository and we'd like to ensure that no further changesets are pushed as a solution is investigated. Thanks, Ir

Re: [14] RFR: 8212970: TZ database in "vanguard" format support

Hi Joe, Thank you for the review. On 7/24/19 2:57 PM, Joe Wang wrote: Hi Naoto, The method findNegativeSavings method in TzdbZoneRulesProvider.java states that it "Find the minimum negative savings". While the result is correct since the rules all have the same value for SAVE, I wonder if t

Re: RFR: 8228507: Archive FDBigInteger

Hi Jiangli, thank you for reviewing! The objects we're dealing with here are all effectively immutable, however, at least one reference field in FDBigInteger is non-final, so putting it in a closed archive region is causing a lot of warnings at dump time. Perhaps we should add a way to suppress s

Re: [14] RFR: 8212970: TZ database in "vanguard" format support

Hi Naoto, The method findNegativeSavings method in TzdbZoneRulesProvider.java states that it "Find the minimum negative savings". While the result is correct since the rules all have the same value for SAVE, I wonder if that's ideal conceptually. Given a start LDT, shouldn't it be looking for

Re: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64

Looks good. On 7/24/2019 7:30 AM, Dmitry Chuyko wrote: Webrev without chdir() and write() changes: http://cr.openjdk.java.net/~dchuyko/8222778/webrev.03/ When it is applied together with webrev.01 [1] from JDK-8228402, sandbox is compiled and passes same jpackage tests on x86, aarch64 and ot

Re: [14] RFR: 8212970: TZ database in "vanguard" format support

Hi Roger, On 7/24/19 1:09 PM, naoto.s...@oracle.com wrote: Thanks for the review, Roger. On 7/24/19 12:47 PM, Roger Riggs wrote: Hi Naoto, Adjusting the data during import looks fine. Typo: TzdbZoneRulesProvider.java:504  "ususally" -> "usually" Will fix it. Removing the source duplica

Re: JDK-8228402: chdir() and write() errors are not handled in jpackage

Hi Andy, I think trowing exception should be better. We do it in several other places, not sure how well our code handles it. I think it might be good idea to file follow up task to cleanup/improve error handling in out native code. For example PosixProcess::Execute() will return false/true, th

Re: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause

> On Jul 23, 2019, at 11:58 PM, Alan Bateman wrote: > > On 23/07/2019 17:41, Brian Burkhalter wrote: >> : >> >> Here is an update which accounts for the foregoing comments. >> >> http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.02/ >>

Re: 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause

Hi Roger, Modified locally. Thanks, Brian > On Jul 24, 2019, at 1:16 PM, Roger Riggs wrote: > > Looks good. > > A nit, In PrintStream.java 597 and 602 : put in the spaces after ",".

Re: 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause

Hi Brian, Looks good. A nit,  In PrintStream.java 597 and 602 : put in the spaces after ",". Thanks, Roger On 7/23/19 2:40 PM, Brian Burkhalter wrote: On Jul 23, 2019, at 10:09 AM, Brian Burkhalter wrote: You will want to add an @throws Will do. The implSpec — * @implSpec

Re: [14] RFR: 8212970: TZ database in "vanguard" format support

Thanks for the review, Roger. On 7/24/19 12:47 PM, Roger Riggs wrote: Hi Naoto, Adjusting the data during import looks fine. Typo: TzdbZoneRulesProvider.java:504  "ususally" -> "usually" Will fix it. Removing the source duplication is good. Is there a way to remove the duplication of th

Re: RFR: 8228581: Archive BigInteger constants

Hi Joe, Jiangli, On 2019-07-24 21:54, Jiangli Zhou wrote: On Wed, Jul 24, 2019 at 12:41 PM Joe Darcy wrote: Hi Claes, For those of us unfamiliar with the archive mechanism, can you describe its semantics or send a pointer to such a description? That's a good point. There are some design do

Re: RFR: 8228581: Archive BigInteger constants

On Wed, Jul 24, 2019 at 12:41 PM Joe Darcy wrote: > > Hi Claes, > > For those of us unfamiliar with the archive mechanism, can you describe > its semantics or send a pointer to such a description? That's a good point. There are some design docs describing how Java objects and object graphs archiv

Re: [14] RFR: 8212970: TZ database in "vanguard" format support

Hi Naoto, Adjusting the data during import looks fine. Typo: TzdbZoneRulesProvider.java:504  "ususally" -> "usually" Removing the source duplication is good. Is there a way to remove the duplication of the TZDATA files themselves? make/data/tzdata/* and test/jdk/sun/til/calendar/zi/* Looks g

Re: RFR: 8228581: Archive BigInteger constants

Hi Claes, For those of us unfamiliar with the archive mechanism, can you describe its semantics or send a pointer to such a description? Thanks, -Joe On 7/24/2019 6:28 AM, Claes Redestad wrote: Hi, BigInteger has a number of pre-calculated constants that are profitable to put up for archiv

Re: [JSR] [JEP] Java Specification Requirement / Java Enhancement Proposal : 'Parallel OR' and 'Parallel AND'

Hello, I don’t think you will get a new infix operator for this. And adding it to existing operators will be acquire risky change, might not improve performance for most situations - and most of all it is quite unlikely that you have a large number of terms at static compile time anyway. Howev

Re: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64

On 7/24/19 3:30 PM, Dmitry Chuyko wrote: > Webrev without chdir() and write() changes: > http://cr.openjdk.java.net/~dchuyko/8222778/webrev.03/ > > When it is applied together with webrev.01 [1] from JDK-8228402, sandbox > is compiled and passes same jpackage tests on x86, aarch64 and other > p

Re: RFR: 8228501: java_props_macosx.c - provide missing CFRelease for CFLocaleCopyCurrent was: RE: java_props_macosx.c : CFLocaleCopyCurrent() needs CFRelease ?

Looks good. Naoto On 7/24/19 12:52 AM, Baesken, Matthias wrote: Hello, seems we need another "CFRelease(cflocale)"in an early return case (see the default: ...) , new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8228501.1/ Best regards, Matthias -Original Message

Re: Review Request: JDK-8219774: Reexamine the initialization of LangReflectAccess shared secret at AccessibleObject::

Hi David, Thanks for the review.   I missed to include you in the reviewer list.  Sorry about that. Mandy On 7/21/19 11:19 PM, David Holmes wrote: Hi Mandy, This approach looks much cleaner and safer to me, and the slight shuffling in the init order should not cause any startup issues. T

Re: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access

On 23/07/2019 19:51, Mandy Chung wrote: (Coming back to this patch and ready to push this change later today) Here is the updated webrev:    http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.02/ This includes the change that Peter suggested accepting m2 == null. The updated isModuleAcces

Re: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64

Webrev without chdir() and write() changes: http://cr.openjdk.java.net/~dchuyko/8222778/webrev.03/ When it is applied together with webrev.01 [1] from JDK-8228402, sandbox is compiled and passes same jpackage tests on x86, aarch64 and other platforms. -Dmitry [1] http://cr.openjdk.java.net/

RFR: 8228581: Archive BigInteger constants

Hi, BigInteger has a number of pre-calculated constants that are profitable to put up for archiving. This reduces initialization time of BigInteger by 0.3-0.5ms, and archives ~12Kb worth of objects. Bug:https://bugs.openjdk.java.net/browse/JDK-8228581 Webrev: http://cr.openjdk.java.net/~rede

Re: Bug in parallel sorting of float / double

Hi Vladimir, On 24/07/2019 10:58 pm, Vladimir Yaroslavskiy wrote: Hi David, Please, see how it works: Arrays.parallelSort(double[]) invokes ArraysParallelSortHelpers.FJDouble.Sorter if size is big enough and ForkJoinPool.getCommonPoolParallelism()) > 1. FJDouble.Sorter divides given array in

Re[2]: Bug in parallel sorting of float / double

Hi David, Please, see how it works: Arrays.parallelSort(double[]) invokes  ArraysParallelSortHelpers.FJDouble.Sorter if size is big enough and ForkJoinPool.getCommonPoolParallelism()) > 1. FJDouble.Sorter divides given array into 4 parts, sorts them recursively in parallel and merges these parts

Re: Bug in parallel sorting of float / double

Hi Vladimir, On 24/07/2019 8:53 pm, Vladimir Yaroslavskiy wrote: Hi all, I've found bug in parallel sorting of float / double arrays in the latest JDK. When float / double values are sorted, additional actions are required: NaNs must be moved to the end and negative zeros must be placed before

Re: DnsClient TCP socket timeout

I have created an issue to track this: https://bugs.openjdk.java.net/browse/JDK-8228580 > Hello list > > Have you ever considered the problem reported here: > > https://stackoverflow.com/questions/14603553/dns-query-freezes-with-dnscontextfactory-in-java > > > A DNS query gets stuck easil

Re: JDK-8228402: chdir() and write() errors are not handled in jpackage

I used assert because: 1.) I don't think it could ever happen. 2.) If it did happen it might be easier to debug with the assert than without it 3.) I thought it would be difficult to propagate the error. but perhaps (3) is not true. would it be better (ignoring types for now) to:     len =

[JSR] [JEP] Java Specification Requirement / Java Enhancement Proposal : 'Parallel OR' and 'Parallel AND'

Hi David / All, Earlier wanted to discuss just the implementation of 'OR operator', neither 'Conditional OR operator', nor 'Bitwise OR operator' Same goes with 'AND operator' Technically OR operator and AND operator are just binary operators, that's true I don't find it wrong considering there

Bug in parallel sorting of float / double

Hi all, I've found bug in parallel sorting of float / double arrays in the latest JDK. When float / double values are sorted, additional actions are required: NaNs must be moved to the end and negative zeros must be placed before positive zeros. Current implementation of Arrays.parallelSort(floa

RE: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer types and string literal conversion warnings

Hi Matthias, I wouldn’t say „looks good”, but I think it’s the right thing to do 😊 The type casts look correct to fit to the AIX headers. libodm_aix: Good. Maybe we should open a new issue for freeing what’s returned by odm_set_path and we could also remove the AIX 5 support. NetworkInterface.c

RFR: 8228507: Archive FDBigInteger

Hi, any double<->String conversion will trigger load of jdk.internal.math.FDBigInteger, which has a static initializer pre-calculating a relatively large number of values. Archiving these pre-calculated values reduces the time spent in FDBigInteger. from a couple of milliseconds down to "nothing

RE: RFR: 8228501: java_props_macosx.c - provide missing CFRelease for CFLocaleCopyCurrent was: RE: java_props_macosx.c : CFLocaleCopyCurrent() needs CFRelease ?

Hello, seems we need another "CFRelease(cflocale)"in an early return case (see the default: ...) , new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8228501.1/ Best regards, Matthias > -Original Message- > From: Baesken, Matthias > Sent: Mittwoch, 24. Juli 2019 08: