Re: RFR: 8289508: Improve test coverage for XPath Axes: ancestor, ancestor-or-self, preceding, and preceding-sibling

On Thu, 8 Sep 2022 06:19:10 GMT, Rahul Prabhu wrote: > Created two files for testing XPath Axes: XPathAncestors.java tests the > ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the > preceding and preceding-sibling axes. It would be nice to cover some of the assertions

Re: [External] : Re: jpackage OS/X --app-image signing

> On Sep 7, 2022, at 1:50 PM, Alexander Matveev > wrote: > > Hi Michael, > > I file following issue for this: > https://bugs.openjdk.org/browse/JDK-8293462 > > > Yes, you right it is related to JDK-8289030. I put suggested workaround to > https

Re: RFR: 8293499: Provide jmod --compress option [v3]

On Mon, 12 Sep 2022 18:34:12 GMT, Aleksey Shipilev wrote: >> I have been looking into `make clean-images images` performance, and >> realized jmod keeps compressing files with default compression level. Tuning >> that toward lighter compression levels improves build performance >> considerably

Re: RFR: 8293499: Provide jmod --compress option [v2]

On Mon, 12 Sep 2022 10:58:41 GMT, Jaikiran Pai wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to >> a merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains three additional >> co

Re: RFR: 8293499: Provide jmod --compress option

On Mon, 12 Sep 2022 15:51:25 GMT, Mark Reinhold wrote: > Agreed. With this approach we can also revise `jlink --compress` to take the > same arguments, keeping `[012]` for compatibility. We can also name this > option `--compress` for `jmod`, rather than `--compression-level`, for > consistenc

Re: RFR: JDK-8293626: AccessFlag::locations(ClassFileFormatVersion cffv) does not throw NPEx when parameter is null

On Mon, 12 Sep 2022 18:14:26 GMT, Joe Darcy wrote: > Small fixes to AccessFlag implementation. LGTM - Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/10243

Re: RFR: 8293499: Provide jmod --compress option [v3]

> I have been looking into `make clean-images images` performance, and realized > jmod keeps compressing files with default compression level. Tuning that > toward lighter compression levels improves build performance considerably, > without a heavy loss in *.jmod sizes. > > This PR allows JMO

RFR: JDK-8293626: AccessFlag::locations(ClassFileFormatVersion cffv) does not throw NPEx when parameter is null

Small fixes to AccessFlag implementation. - Commit messages: - JDK-8293626: AccessFlag::locations(ClassFileFormatVersion cffv) does not throw NPEx when parameter is null Changes: https://git.openjdk.org/jdk/pull/10243/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10243&ra

Re: RFR: 8289508: Improve test coverage for XPath Axes: ancestor, ancestor-or-self, preceding, and preceding-sibling

On Thu, 8 Sep 2022 15:54:03 GMT, Rajan Halade wrote: >> Created two files for testing XPath Axes: XPathAncestors.java tests the >> ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the >> preceding and preceding-sibling axes. > > Please fix jcheck issues. Code has trailing

Re: RFR: 8293499: Provide jmod compression level option

On Mon, 12 Sep 2022 11:48:50 GMT, Claes Redestad wrote: > > Meaning, we allow `--compress=zip-[0..9]` and default to `zip-6`. This has > > the added benefit of clearly stating that `zip-0` is still ZIP, but without > > the compression applied. This is a bit ambiguous with > > `--compression-le

Re: RFR: 8290367: Update default value and extend the scope of com.sun.jndi.ldap.object.trustSerialData system property [v3]

> ### Summary of the change > > The LDAP Naming Service Provider implementation's default settings are > changed to disallow deserialization and reconstruction of Java objects from > different LDAP attributes (RFC 2713). Currently, only the deserialization is > controlled by the `com.sun.jndi.l

Integrated: 8287908: Use non-cloning reflection methods where acceptable

On Tue, 7 Jun 2022 13:45:06 GMT, Сергей Цыпанов wrote: > Instead of `Executable.getParameterTypes()` we could use > `Executable.getSharedParameterTypes()` in trusted code. Same is applicable > for `Executable.getExceptionTypes()`. This pull request has now been integrated. Changeset: 9ef6c092

Integrated: 8293282: LoadLibraryUnloadTest.java fails with "Too few cleared WeakReferences"

On Thu, 8 Sep 2022 20:26:41 GMT, Roger Riggs wrote: > Modify the LoadLibraryUnload test to call gc() more a few times, allowing > multiple gc cycles to queue the expected refs. > Short the timeout on each cycle to 10 sec. This pull request has now been integrated. Changeset: 0c61bf10 Author:

Re: RFR: 8293282: LoadLibraryUnloadTest.java fails with "Too few cleared WeakReferences" [v3]

On Fri, 9 Sep 2022 15:48:41 GMT, Roger Riggs wrote: >> Modify the LoadLibraryUnload test to call gc() more a few times, allowing >> multiple gc cycles to queue the expected refs. >> Short the timeout on each cycle to 10 sec. > > Roger Riggs has updated the pull request incrementally with one add

Re: RFR: 8290367: Update default value and extend the scope of com.sun.jndi.ldap.object.trustSerialData system property [v2]

On Mon, 12 Sep 2022 10:53:10 GMT, Jaikiran Pai wrote: > is there a convention in our documentation where we state that the value is > case insensitive? I think there isn't. Therefore, it will be cleaner to update the property description in `module-info.java` to something like: `"the system pr

Re: RFR: 8290367: Update default value and extend the scope of com.sun.jndi.ldap.object.trustSerialData system property [v2]

On Mon, 12 Sep 2022 12:06:07 GMT, Jaikiran Pai wrote: >> Aleksei Efimov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Add run for the SP w/o value, formatting/wording updates > > test/jdk/com/sun/jndi/ldap/objects/RemoteLocationAttribu

Re: RFR: 8290367: Update default value and extend the scope of com.sun.jndi.ldap.object.trustSerialData system property [v2]

On Fri, 9 Sep 2022 16:55:44 GMT, Aleksei Efimov wrote: >> ### Summary of the change >> >> The LDAP Naming Service Provider implementation's default settings are >> changed to disallow deserialization and reconstruction of Java objects from >> different LDAP attributes (RFC 2713). Currently, on

Re: RFR: 8293499: Provide jmod compression level option

On Mon, 12 Sep 2022 11:20:14 GMT, Aleksey Shipilev wrote: > Meaning, we allow `--compress=zip-[0..9]` and default to `zip-6`. This has > the added benefit of clearly stating that `zip-0` is still ZIP, but without > the compression applied. This is a bit ambiguous with `--compression-level=0`.

Re: RFR: 8293499: Provide jmod compression level option

On Mon, 12 Sep 2022 10:48:53 GMT, Claes Redestad wrote: > The part about being open-ended about alternate compression algorithms still > applies, but since the compression for `jmod` is currently always zip we can > defer such wording for if/when that day comes. Well, we can future-proof it by

Re: RFR: 8290367: Update default value and extend the scope of com.sun.jndi.ldap.object.trustSerialData system property [v2]

On Mon, 12 Sep 2022 10:48:01 GMT, Jaikiran Pai wrote: >> Aleksei Efimov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Add run for the SP w/o value, formatting/wording updates > > src/java.naming/share/classes/com/sun/jndi/ldap/VersionH

Re: RFR: 8293499: Provide jmod compression level option [v2]

On Mon, 12 Sep 2022 10:48:16 GMT, Aleksey Shipilev wrote: >> I have been looking into `make clean-images images` performance, and >> realized jmod keeps compressing files with default compression level. Tuning >> that toward lighter compression levels improves build performance >> considerably

Re: RFR: 8292698: Improve performance of DataInputStream [v4]

On Mon, 29 Aug 2022 08:46:20 GMT, Сергей Цыпанов wrote: >> I found out that reading from `DataInputStream` wrapping >> `ByteArrayInputStream` (as well as `BufferedInputStream` or any >> `InputStream` relying on `byte[]`) can be significantly improved by >> accessing volatile `in` field only on

Re: RFR: 8293499: Provide jmod compression level option [v2]

On Mon, 12 Sep 2022 10:48:16 GMT, Aleksey Shipilev wrote: >> I have been looking into `make clean-images images` performance, and >> realized jmod keeps compressing files with default compression level. Tuning >> that toward lighter compression levels improves build performance >> considerably

Re: RFR: 8290367: Update default value and extend the scope of com.sun.jndi.ldap.object.trustSerialData system property [v2]

On Fri, 9 Sep 2022 16:55:44 GMT, Aleksei Efimov wrote: >> ### Summary of the change >> >> The LDAP Naming Service Provider implementation's default settings are >> changed to disallow deserialization and reconstruction of Java objects from >> different LDAP attributes (RFC 2713). Currently, on

Re: RFR: 8290367: Update default value and extend the scope of com.sun.jndi.ldap.object.trustSerialData system property [v2]

On Fri, 9 Sep 2022 16:55:44 GMT, Aleksei Efimov wrote: >> ### Summary of the change >> >> The LDAP Naming Service Provider implementation's default settings are >> changed to disallow deserialization and reconstruction of Java objects from >> different LDAP attributes (RFC 2713). Currently, on

Re: RFR: 8293499: Provide jmod compression level option

On Mon, 12 Sep 2022 10:26:56 GMT, Aleksey Shipilev wrote: > Um, this is `jmod`, it does not have `--compress=...` option? `jlink` does. > So, I don't quite understand this comment :) Doh! Yes, I mixed up the two and assumed you'd be considering this for `jlink` as well. The part about being op

Re: RFR: 8293499: Provide jmod compression level option

On Mon, 12 Sep 2022 10:18:40 GMT, Jaikiran Pai wrote: > Should we instead complain/fail when this option is used for anything other > than `create`? Good idea, see new commit. - PR: https://git.openjdk.org/jdk/pull/10213

Re: RFR: 8293499: Provide jmod compression level option [v2]

> I have been looking into `make clean-images images` performance, and realized > jmod keeps compressing files with default compression level. Tuning that > toward lighter compression levels improves build performance considerably, > without a heavy loss in *.jmod sizes. > > This PR allows JMO

Re: RFR: 8293499: Provide jmod compression level option

On Mon, 12 Sep 2022 10:15:26 GMT, Jaikiran Pai wrote: >> I have been looking into `make clean-images images` performance, and >> realized jmod keeps compressing files with default compression level. Tuning >> that toward lighter compression levels improves build performance >> considerably, wi

Re: RFR: 8293499: Provide jmod compression level option

On Mon, 12 Sep 2022 10:13:12 GMT, Claes Redestad wrote: > Could we word this so that the accepted values is compression-dependent? The > value appears to be ignored for `--compress=0|1` (should it throw if > specified or not specified to, say, 0?). We might also add other compressions > in the

Re: RFR: 8293499: Provide jmod compression level option

On Thu, 8 Sep 2022 07:57:36 GMT, Aleksey Shipilev wrote: > I have been looking into `make clean-images images` performance, and realized > jmod keeps compressing files with default compression level. Tuning that > toward lighter compression levels improves build performance considerably, > wit

Re: RFR: 8293499: Provide jmod compression level option

On Thu, 8 Sep 2022 07:57:36 GMT, Aleksey Shipilev wrote: > I have been looking into `make clean-images images` performance, and realized > jmod keeps compressing files with default compression level. Tuning that > toward lighter compression levels improves build performance considerably, > wit

Re: RFR: 8293499: Provide jmod compression level option

On Thu, 8 Sep 2022 07:57:36 GMT, Aleksey Shipilev wrote: > I have been looking into `make clean-images images` performance, and realized > jmod keeps compressing files with default compression level. Tuning that > toward lighter compression levels improves build performance considerably, > wit

Re: RFR: 8292698: Improve performance of DataInputStream [v3]

On Thu, 25 Aug 2022 09:25:55 GMT, Alan Bateman wrote: >> Btw, I've tried to reimplement `readInt()` in a way similar to `readLong()`: >> >> public final int readInt() throws IOException { >> readFully(readBuffer, 0, 4); >> return (readBuffer[0] & 0xff) << 24 >> + (readBuffer[1]

Re: RFR: 8293499: Provide jmod compression level option

On Thu, 8 Sep 2022 07:57:36 GMT, Aleksey Shipilev wrote: > I have been looking into `make clean-images images` performance, and realized > jmod keeps compressing files with default compression level. Tuning that > toward lighter compression levels improves build performance considerably, > wit

Re: RFR: 8293630: Simplify TreeMap.get() with Comparator.naturalOrder()

On Wed, 17 Aug 2022 11:23:57 GMT, Сергей Цыпанов wrote: > We can use `Comparator.naturalOrder()` for cases when a `TreeMap` instance is > constructed without comparator. This allows to squash two branches in > `TreeMap.get()` into one. > > P.S. I think the comment of `TreeMap.getEntryUsingComp

Re: RFR: 8293630: Simplify TreeMap.get() with Comparator.naturalOrder()

On Sat, 20 Aug 2022 16:37:29 GMT, liach wrote: >> We can use `Comparator.naturalOrder()` for cases when a `TreeMap` instance >> is constructed without comparator. This allows to squash two branches in >> `TreeMap.get()` into one. >> >> P.S. I think the comment of `TreeMap.getEntryUsingComparat

RFR: 8293630: Simplify TreeMap.get() with Comparator.naturalOrder()

We can use `Comparator.naturalOrder()` for cases when a `TreeMap` instance is constructed without comparator. This allows to squash two branches in `TreeMap.get()` into one. P.S. I think the comment of `TreeMap.getEntryUsingComparator()` is outdated. Should we also change it? - Co

Re: RFR: 8290367: Update default value and extend the scope of com.sun.jndi.ldap.object.trustSerialData system property [v2]

On Fri, 9 Sep 2022 16:55:44 GMT, Aleksei Efimov wrote: >> ### Summary of the change >> >> The LDAP Naming Service Provider implementation's default settings are >> changed to disallow deserialization and reconstruction of Java objects from >> different LDAP attributes (RFC 2713). Currently, on