Integrated: JDK-8289551: Conversions between bit representations of half precision values and floats

2022-07-26 Thread Joe Darcy
On Fri, 8 Jul 2022 06:11:22 GMT, Joe Darcy wrote: > Initial implementation. This pull request has now been integrated. Changeset: 7318b222 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/7318b22209a83c593176ec600647a9b050362932 Stats: 703 lines in 3 files changed:

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v9]

2022-07-25 Thread Joe Darcy
> Initial implementation. Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: - Adopt alternative implementaiton from review. - Refactor equivalent() implementation. - Changes: - all: https://git.openjdk.org/jdk/pull/9

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v8]

2022-07-25 Thread Joe Darcy
> Initial implementation. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Implement additional review feedback. - Changes: - all: https://git.openjdk.org/jdk/pull/9422/files - new: https://git.openjdk.org/jdk/pull/9

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v7]

2022-07-25 Thread Joe Darcy
> Initial implementation. Joe Darcy 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 23 additional commits since the last revision: - Implem

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v6]

2022-07-25 Thread Joe Darcy
On Sat, 23 Jul 2022 18:00:12 GMT, Raffaello Giulietti wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Implement review feedback. > > src/java.base/share/classes/java/lang/Fl

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v6]

2022-07-25 Thread Joe Darcy
On Sat, 23 Jul 2022 16:38:34 GMT, Raffaello Giulietti wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Implement review feedback. > > src/java.base/share/classes/java/lang/Float.jav

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v6]

2022-07-21 Thread Joe Darcy
> Initial implementation. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Implement review feedback. - Changes: - all: https://git.openjdk.org/jdk/pull/9422/files - new: https://git.openjdk.org/jdk/pull/9422/fi

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v5]

2022-07-21 Thread Joe Darcy
On Thu, 21 Jul 2022 21:22:19 GMT, Joe Darcy wrote: >> Initial implementation. > > Joe Darcy 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 r

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v5]

2022-07-21 Thread Joe Darcy
> Initial implementation. Joe Darcy 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 20 additional commits since the last revision: - Method ren

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v4]

2022-07-18 Thread Joe Darcy
On Mon, 18 Jul 2022 20:30:21 GMT, Joe Darcy wrote: >> Initial implementation. > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Add NaN test. I added NaN round-trip tests is a separate file since the prop

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v4]

2022-07-18 Thread Joe Darcy
> Initial implementation. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Add NaN test. - Changes: - all: https://git.openjdk.org/jdk/pull/9422/files - new: https://git.openjdk.org/jdk/pull/9422/files/420a9

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v3]

2022-07-15 Thread Joe Darcy
> Initial implementation. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Preserve NaN sign bit. - Changes: - all: https://git.openjdk.org/jdk/pull/9422/files - new: https://git.openjdk.org/jdk/pull/9422/files/b09fd

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v2]

2022-07-15 Thread Joe Darcy
> Initial implementation. Joe Darcy 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 15 additional commits since the last revision: - Resp

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats

2022-07-15 Thread Joe Darcy
On Wed, 13 Jul 2022 13:11:33 GMT, Raffaello Giulietti wrote: >> Initial implementation. > > src/java.base/share/classes/java/lang/Float.java line 1174: > >> 1172: >> 1173: short result = 0; >> 1174: result = (short)(((exp + 15) << 10) | signif_bits); > > result =

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats

2022-07-14 Thread Joe Darcy
On Wed, 13 Jul 2022 12:28:29 GMT, Raffaello Giulietti wrote: >> Initial implementation. > > src/java.base/share/classes/java/lang/Float.java line 1090: > >> 1088: public static short floatToBinary16AsShortBits(float f) { >> 1089: if (Float.isNaN(f)) { >> 1090: //

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats

2022-07-14 Thread Joe Darcy
On Wed, 13 Jul 2022 14:33:49 GMT, Raffaello Giulietti wrote: >> Initial implementation. > > test/jdk/java/lang/Float/SixteenBitFormats.java line 239: > >> 237: public static boolean isNaN(short binary16) { >> 238: return ((binary16 & 0x7c00) == 0x7c00) // Max exponent >>

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats

2022-07-14 Thread Joe Darcy
On Wed, 13 Jul 2022 12:38:23 GMT, Raffaello Giulietti wrote: >> Initial implementation. > > src/java.base/share/classes/java/lang/Float.java line 1100: > >> 1098: >> 1099: // The overflow threshold is binary16 MAX_VALUE + 1/2 ulp >> 1100: if (abs_f > (65504.0f + 16.0f) ) { > >

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats

2022-07-14 Thread Joe Darcy
On Thu, 14 Jul 2022 20:54:59 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/lang/Float.java line 1100: >> >>> 1098: >>> 1099: // The overflow threshold is binary16 MAX_VALUE + 1/2 ulp >>> 1100: if (abs_f > (65504.0f + 16.0f)

Re: RFR: JDK-8289106: Add model of class file versions to core reflection [v2]

2022-07-13 Thread Joe Darcy
On Mon, 11 Jul 2022 20:31:04 GMT, Mandy Chung wrote: > This `ClassFileFormatVersion` API is a good proposal. It can also reference > `java.class.version` system property to map to the latest class file format > version. Good idea Mandy; I'll add that reference and start working on the

Re: RFR: 8288933: Improve the implementation of Double/Float.isInfinite

2022-07-13 Thread Joe Darcy
On Wed, 22 Jun 2022 12:43:53 GMT, Quan Anh Mai wrote: > Improve the implementation of `Double/Float.isInfinite` to reduce branching. > Using `>` comparison with `MAX_VALUE` instead of `==` with > `POSITIVE_INFINITY` improves code emission on x86 and produces similar code > for arm. This is

Re: RFR: 8290079: Reduce interaction with volatile in static initializer of BigInteger [v2]

2022-07-13 Thread Joe Darcy
On Wed, 13 Jul 2022 15:32:18 GMT, Сергей Цыпанов wrote: >> `BigInteger.powerCache` is volatile and should be assigned only once in >> static initializer. > > Сергей Цыпанов has updated the pull request incrementally with one additional > commit since the last revision: > > 8290079: Rename

Re: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats

2022-07-13 Thread Joe Darcy
On Fri, 8 Jul 2022 06:11:22 GMT, Joe Darcy wrote: > Initial implementation. Some notes in the current implementation in the PR: the impetus for the change is to provide a minimal level of platform support for the binary16 floating-point format defined in IEEE 754. This is done by added

Re: RFR: JDK-8289775: Update java.lang.invoke.MethodHandle[s] to use snippets

2022-07-07 Thread Joe Darcy
On Wed, 6 Jul 2022 20:49:25 GMT, John R Rose wrote: > The code examples in these files were exdented to make it easier to extract > example code and test it, and to maintain equivalence during active > development of the APIs. > > The examples in runnable form are in >

Re: RFR: JDK-8289775: Update java.lang.invoke.MethodHandle[s] to use snippets

2022-07-07 Thread Joe Darcy
On Wed, 6 Jul 2022 00:08:04 GMT, liach wrote: >> Update existing examples in java.lang.invoke.{MethodHandle, MethodHandles} >> to use snippets rather than the older markup idiom. > > src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 272: > >> 270: * Here are some examples

RFR: JDK-8289775: Update java.lang.invoke.MethodHandle[s] to use snippets

2022-07-06 Thread Joe Darcy
Update existing examples in java.lang.invoke.{MethodHandle, MethodHandles} to use snippets rather than the older markup idiom. - Commit messages: - JDK-8289775: Update java.lang.invoke.MethodHandle[s] to use snippets Changes: https://git.openjdk.org/jdk/pull/9385/files Webrev:

Re: RFR: JDK-8289730 : Deprecated code in src/java.base/share/classes/java/lang/ClassCastException.java

2022-07-05 Thread Joe Darcy
On Mon, 4 Jul 2022 06:57:12 GMT, ScientificWare wrote: > - Correct a deprecated code. > - Update Copyright. > - More wide question : How are you dealing with deprecated codes in snippets ? > ``` > @deprecated(since="9") > public Integer​(int value) > ``` Looks fine. There is as of yet

Re: RFR: JDK-8289106: Add model of class file versions to core reflection

2022-06-29 Thread Joe Darcy
On Wed, 29 Jun 2022 16:51:21 GMT, Roger Riggs wrote: > I'm thinking of the case where I'm reading class file bytes and pull out the > major classfile version and want to map it to the enum. If the semantic was > the "earliest version" supporting the major version then it would be >

Re: RFR: JDK-8289106: Add model of class file versions to core reflection [v2]

2022-06-29 Thread Joe Darcy
> JDK-8289106: Add model of class file versions to core reflection Joe Darcy 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 10 additional comm

Re: RFR: 8289260: BigDecimal movePointLeft() and movePointRight() do not follow their API spec [v2]

2022-06-29 Thread Joe Darcy
On Tue, 28 Jun 2022 10:32:31 GMT, Raffaello Giulietti wrote: >> `BigDecimal.morePoint[Left|Right]()` should return the target `this` when >> the argument is 0 _and_ the scale is non-negative. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since

Re: RFR: 8289260: BigDecimal movePointLeft() and movePointRight() do not follow their API spec [v2]

2022-06-29 Thread Joe Darcy
On Tue, 28 Jun 2022 10:32:31 GMT, Raffaello Giulietti wrote: >> `BigDecimal.morePoint[Left|Right]()` should return the target `this` when >> the argument is 0 _and_ the scale is non-negative. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since

Re: RFR: JDK-8289106: Add model of class file versions to core reflection

2022-06-29 Thread Joe Darcy
On Wed, 29 Jun 2022 14:42:19 GMT, Roger Riggs wrote: > A static method to map from classfile version (as in the JVMS) to > ClassFileVersion enum will be useful too. Just to confirm, you're asking for a method that would map 63 to RELEASE_19, 64 to RELEASE_20, etc.? Seems reasonable, although

Re: RFR: JDK-8289106: Add model of class file versions to core reflection

2022-06-28 Thread Joe Darcy
On Mon, 27 Jun 2022 20:26:52 GMT, Joe Darcy wrote: > JDK-8289106: Add model of class file versions to core reflection Sending this enum to model class file format versions out for some review comments before starting to write the tests and CSR, etc. The class file format has a rich struct

RFR: JDK-8289106: Add model of class file versions to core reflection

2022-06-28 Thread Joe Darcy
JDK-8289106: Add model of class file versions to core reflection - Commit messages: - Update phrasing. - Augment and correct docs. - Correct major versions; RELEASE_0 and RELEASE_1 are both 45. - Make major method public. - Add AccessFlag.locations(ClassFileFormatVersion) - Add

Integrated: JDK-8266670: Better modeling of access flags in core reflection

2022-06-25 Thread Joe Darcy
On Fri, 11 Feb 2022 18:31:57 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 fla

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

2022-06-25 Thread Joe Darcy
uced. > > This PR in its current form is meant to give the overall shape of the API. It > is missing implementations to map from, say, method modifiers to access > flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be fill

Re: RFR: 8288021: Add hard test cases to jdk.internal.math.DoubleToDecimalChecker

2022-06-24 Thread Joe Darcy
On Wed, 8 Jun 2022 13:12:09 GMT, Raffaello Giulietti wrote: > These 19'545 doubles were generated on purpose by Paul Zimmermann of INRIA as > hard test cases. Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.org/jdk/pull/9084

Re: RFR: 8288596: Random:from() adapter does not delegate to supplied generator in all cases

2022-06-24 Thread Joe Darcy
On Fri, 17 Jun 2022 16:44:30 GMT, Raffaello Giulietti wrote: > Extend delegation by instance returned by Random.from() to all methods > exposed by RandomGenerator. Looks fine. I agree this implementation is more in keeping with the intent of the specification. - Marked as

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

2022-06-23 Thread Joe Darcy
On Thu, 23 Jun 2022 14:37:42 GMT, Roger Riggs wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove implSpec tag from Executable.accessFlags since the class is sealed. > > src/jav

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

2022-06-23 Thread Joe Darcy
uced. > > This PR in its current form is meant to give the overall shape of the API. It > is missing implementations to map from, say, method modifiers to access > flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be fill

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

2022-06-23 Thread Joe Darcy
On Wed, 22 Jun 2022 17:33:25 GMT, Mandy Chung wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove implSpec tag from Executable.accessFlags since the class is sealed. > > src/jav

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

2022-06-23 Thread Joe Darcy
On Tue, 14 Jun 2022 14:22:29 GMT, Roger Riggs wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Respond to review feedback. > > src/java.base/share/classes/java/lang/reflect/Acces

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

2022-06-21 Thread Joe Darcy
uced. > > This PR in its current form is meant to give the overall shape of the API. It > is missing implementations to map from, say, method modifiers to access > flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be fill

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

2022-06-21 Thread Joe Darcy
On Fri, 29 Apr 2022 18:49:26 GMT, Mandy Chung wrote: >> Joe Darcy 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 26

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

2022-06-21 Thread Joe Darcy
uced. > > This PR in its current form is meant to give the overall shape of the API. It > is missing implementations to map from, say, method modifiers to access > flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be fill

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

2022-06-21 Thread Joe Darcy
uced. > > This PR in its current form is meant to give the overall shape of the API. It > is missing implementations to map from, say, method modifiers to access > flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be fill

Integrated: JDK-8288573: Make Executable.getParameterCount() actually abstract

2022-06-17 Thread Joe Darcy
On Thu, 16 Jun 2022 21:21:36 GMT, Joe Darcy wrote: > Whatever the motivation for how this method was coded when added in JDK 8, > since Executable is now a sealed class with Constructor and Method the only > allowed subclasses, getParameterCount can be coded as an normal abstract

Re: RFR: JDK-8288573: Make Executable.getParameterCount() actually abstract [v2]

2022-06-17 Thread Joe Darcy
nt in Method and Constructor > use fields private to each of those classes so the code cannot easily be > shared in Executable). > > Please also review the small accompanying CSR: > https://bugs.openjdk.org/browse/JDK-8288630 Joe Darcy has updated the pull request incrementally with o

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

2022-06-16 Thread Joe Darcy
uced. > > This PR in its current form is meant to give the overall shape of the API. It > is missing implementations to map from, say, method modifiers to access > flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be fill

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

2022-06-16 Thread Joe Darcy
uced. > > This PR in its current form is meant to give the overall shape of the API. It > is missing implementations to map from, say, method modifiers to access > flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be fill

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

2022-06-16 Thread Joe Darcy
On Thu, 16 Jun 2022 08:21:49 GMT, ExE Boss wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Respond to review feedback. > > src/java.base/share/classes/java/lang/reflect/Member.java line

RFR: JDK-8288573: Make `java.lang.reflect.Executable::getParameterCount()' actually abstract

2022-06-16 Thread Joe Darcy
Whatever the motivation for how this method was coded when added in JDK 8, since Executable is now a sealed class with Constructor and Method the only allowed subclasses, getParameterCount can be coded as an normal abstract method. (The implementation of getParameterCount in Method and

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

2022-06-16 Thread Joe Darcy
On Thu, 16 Jun 2022 06:27:59 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 leve

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

2022-06-16 Thread Joe Darcy
uced. > > This PR in its current form is meant to give the overall shape of the API. It > is missing implementations to map from, say, method modifiers to access > flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be fill

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

2022-06-16 Thread Joe Darcy
uced. > > This PR in its current form is meant to give the overall shape of the API. It > is missing implementations to map from, say, method modifiers to access > flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be fill

<    3   4   5   6   7   8