Re: RFR: 8279598: Provide adapter from RandomGenerator to Random [v15]

> Hi, could i get a review on this implementation proposed by Stuart Marks, i > decided to use the > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html > interface to create the default method `asRandom()` that wraps around the > newer algorithms

Re: RFR: 8279598: Provide adapter from RandomGenerator to Random [v14]

On Sat, 5 Mar 2022 19:48:47 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i >> decided to use the >> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html >> interface to create the default

Re: Replace simple iterations of Map.entrySet with Map.forEach calls

I've made a benchmark with visualized results on putting a map of a

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

> This is an early review of changes to better model JVM access flags, that is > "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but > distinct. There are concepts that overlap in the two domains

Re: RFR: 8279598: Provide adapter from RandomGenerator to Random [v13]

On Sat, 5 Mar 2022 19:39:41 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i >> decided to use the >> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html >> interface to create the default

Re: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v27]

On Sat, 5 Mar 2022 19:29:17 GMT, liach wrote: > this looks wrong, and the class instance is used nowhere later. should > probably be removed. @liach already removed in the latest commit. - PR: https://git.openjdk.java.net/jdk/pull/7431

Re: RFR: 8279598: Provide adapter from RandomGenerator to Random [v14]

> Hi, could i get a review on this implementation proposed by Stuart Marks, i > decided to use the > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html > interface to create the default method `asRandom()` that wraps around the > newer algorithms

Re: RFR: 8279598: Provide adapter from RandomGenerator to Random [v13]

> Hi, could i get a review on this implementation proposed by Stuart Marks, i > decided to use the > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html > interface to create the default method `asRandom()` that wraps around the > newer algorithms

Re: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v27]

On Sat, 5 Mar 2022 19:06:03 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional > commit since the last revision: > > refactor tests

Re: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v27]

> 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: refactor tests - Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new:

Re: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v26]

> 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with three additional commits since the last revision: - refactor tests - refactor tests - refactor WhiteBoxResizeTest - Changes: - all:

Re: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException [v3]

On Sat, 5 Mar 2022 03:29:44 GMT, Joe Darcy wrote: >> Occasionally in core-libs we've discussed whether or not to do a pass over >> the exception classes and proactively add any of four missing convention >> constructors per java.lang.Throwable (no-arg, string, cause, cause and >> string).

Re: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException [v3]

On Sat, 5 Mar 2022 03:29:44 GMT, Joe Darcy wrote: >> Occasionally in core-libs we've discussed whether or not to do a pass over >> the exception classes and proactively add any of four missing convention >> constructors per java.lang.Throwable (no-arg, string, cause, cause and >> string).

Re: RFR: 8282701: Use Class.getInterfaces(false) where possible to reduce allocation pressure

This method is now called in java.lang.ClassLoader, which can only call package-private java.lang.Class methods. This is a safe change as this won't expose the raw array to any untrusted code. On Sat, Mar 5, 2022 at 10:22 AM Bernd Eckenfels wrote: > Should probably explain why it removes the

Re: RFR: 8282701: Use Class.getInterfaces(false) where possible to reduce allocation pressure

Should probably explain why it removes the private modifier? Gruss Bernd -- http://bernd.eckenfels.net Von: core-libs-dev im Auftrag von Сергей Цыпанов Gesendet: Saturday, March 5, 2022 2:14:20 PM An: core-libs-dev@openjdk.java.net Betreff: RFR: 8282701: Use

Re: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v3]

On Fri, 4 Mar 2022 21:17:50 GMT, Jim Laskey wrote: >> Several attempts have been made to improve Formatter's numeric performance >> by caching the current Locale zero. Such fixes, however, ignore the real >> issue, which is the slowness of fetching DecimalFormatSymbols. By directly >> caching

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v16]

On Tue, 1 Mar 2022 02:11:26 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >>

RFR: 8282701: Use Class.getInterfaces(false) where possible to reduce allocation pressure

`Class.getInterfaces(false)` does not clone underlying array and can be used in cases when the returned array is only read from. - Commit messages: - 8282701: Use Class.getInterfaces(false) where possible to reduce allocation pressure Changes:

Re: Replace simple iterations of Map.entrySet with Map.forEach calls

- Original Message - > From: "Stuart Marks" > To: "-" , "core-libs-dev" > > Sent: Saturday, March 5, 2022 1:58:30 AM > Subject: Re: Replace simple iterations of Map.entrySet with Map.forEach calls > Hi, I have to say I'm pretty skeptical of this change overall. > > It sounds like the

Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops

On Fri, 4 Mar 2022 17:14:34 GMT, Claes Redestad wrote: >> Despite the hash value being cached for Strings, computing the hash still >> represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to