On Thu, 10 Nov 2022 17:42:04 GMT, Jim Laskey wrote:
>> Enhance the Java programming language with string templates, which are
>> similar to string literals but contain embedded expressions. A string
>> template is interpreted at run time by replacing each expression with the
>> result of evalu
On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad wrote:
>> Continuing the work initiated by @luhenry to unroll and then intrinsify
>> polynomial hash loops.
>>
>> I've rewired the library changes to route via a single `@IntrinsicCandidate`
>> method. To make this work I've harmonized how they
On Sat, 12 Nov 2022 00:55:56 GMT, Vladimir Ivanov wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Missing & 0xff in StringLatin1::hashCode
>
> src/hotspot/cpu/x86/x86_64.ad line 12081:
>
>> 12079: format %{ "A
On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad wrote:
>> Continuing the work initiated by @luhenry to unroll and then intrinsify
>> polynomial hash loops.
>>
>> I've rewired the library changes to route via a single `@IntrinsicCandidate`
>> method. To make this work I've harmonized how they
On Tue, 8 Nov 2022 16:04:25 GMT, Roger Riggs wrote:
>> Process.waitFor() throws IllegalThreadStateException when a process returns
>> an exit code of 259.
>> As described in the bug report, `waitFor()` should not be sensitive to the
>> exit value.
>> Previously, it erroneously threw IllegalStat
On Thu, 10 Nov 2022 12:33:05 GMT, Jaikiran Pai wrote:
> One final question - Now with this change, `Process.waitFor()` won't throw
> the `IllegalThreadStateException` for such programs that return
> `STILL_ACTIVE` exit code. However, looking at the code a subsequent
> Process.exitValue() call
On Fri, 11 Nov 2022 17:46:08 GMT, Alan Bateman wrote:
> I think it would be useful to generate the javadoc and see if there are
> terminology or wording differences between the existing and new descriptions
> being copied down from input stream.
>
> For example, the no-arg read is "Reads a byt
> Please review the following PR which updates several of the ZipInputStream
> methods whose javadoc is inherited to clarify the methods are acting on the
> current ZIP Entry.
>
> There are no changes in behavior. The main description for the method's
> javadoc that has been copied has been
On Fri, 11 Nov 2022 17:16:38 GMT, Lance Andersen wrote:
>> Please review the following PR which updates several of the ZipInputStream
>> methods whose javadoc is inherited to clarify the methods are acting on
>> the current ZIP Entry.
>>
>> There are no changes in behavior. The main descrip
On Wed, 9 Nov 2022 07:11:53 GMT, Markus KARG wrote:
>> This PR implements JDK-8296431
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Removed unused imports
Marked as reviewed by bpb (Reviewer).
-
PR: https://
On Fri, 11 Nov 2022 12:22:32 GMT, Alan Bateman wrote:
>> Lance Andersen has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Addressed latest set of input on the javadoc
>
> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 2
On Fri, 4 Nov 2022 18:13:23 GMT, Lance Andersen wrote:
> Please review the following PR which updates several of the ZipInputStream
> methods whose javadoc is inherited to clarify the methods are acting on the
> current ZIP Entry.
>
> There are no changes in behavior. The main description f
> Please review the following PR which updates several of the ZipInputStream
> methods whose javadoc is inherited to clarify the methods are acting on the
> current ZIP Entry.
>
> There are no changes in behavior. The main description for the method's
> javadoc that has been copied has been
I'd be hesitant to do that in decimal; it's probably better to add
`0x1.0p63` instead. But I guess the approaches are similar: shave off one
bit, and then test that bit and adjust the result accordingly.
On Fri, Nov 11, 2022 at 9:59 AM Remi Forax wrote:
> Hi all,
> I don't know if it's the corre
Hi all,
I don't know if it's the correct way to do it or if there is a better way, but
i'm using
var result = (double) (value & 0x7fffL );
if (value < 0) {
result = result + 9.223372036854776E18;
}
The idea is to mask the sign bit, do the conversion to double and if the sign
b
On Fri, 11 Nov 2022 12:32:10 GMT, Alan Bateman wrote:
> I don't have any other comments. @bplb told me that he would sponsor this for
> you.
Thanks, but I need a successful review logged first. :-)
-
PR: https://git.openjdk.org/jdk/pull/10999
On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad wrote:
>> Continuing the work initiated by @luhenry to unroll and then intrinsify
>> polynomial hash loops.
>>
>> I've rewired the library changes to route via a single `@IntrinsicCandidate`
>> method. To make this work I've harmonized how they
Well, I typed this out from memory so there's an error, of course. `(tmp &
1)` should be `(input & 1)`.
On Fri, Nov 11, 2022 at 8:31 AM David Lloyd wrote:
> I encountered this issue as well; for now I'm using the following
> transformation:
>
> long tmp = input >>> 1;
> double output = ((double)
I encountered this issue as well; for now I'm using the following
transformation:
long tmp = input >>> 1;
double output = ((double) tmp) * 2.0 + (tmp & 1);
I... *think* it's correct but I'm not 100% sure and have a long-standing
TODO to try and figure it out...
On Sat, Nov 5, 2022 at 7:17 PM Joh
On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad wrote:
>> Continuing the work initiated by @luhenry to unroll and then intrinsify
>> polynomial hash loops.
>>
>> I've rewired the library changes to route via a single `@IntrinsicCandidate`
>> method. To make this work I've harmonized how they
On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad wrote:
>> Continuing the work initiated by @luhenry to unroll and then intrinsify
>> polynomial hash loops.
>>
>> I've rewired the library changes to route via a single `@IntrinsicCandidate`
>> method. To make this work I've harmonized how they
On Thu, 10 Nov 2022 15:03:26 GMT, Claes Redestad wrote:
>> Continuing the work initiated by @luhenry to unroll and then intrinsify
>> polynomial hash loops.
>>
>> I've rewired the library changes to route via a single `@IntrinsicCandidate`
>> method. To make this work I've harmonized how they
> Continuing the work initiated by @luhenry to unroll and then intrinsify
> polynomial hash loops.
>
> I've rewired the library changes to route via a single `@IntrinsicCandidate`
> method. To make this work I've harmonized how they are invoked so that
> there's less special handling and checks
On Fri, 11 Nov 2022 12:36:20 GMT, Daniel Fuchs wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Qualified guess on shenandoahSupport fix-up
>
> src/java.base/share/classes/java/lang/StringLatin1.java line 194:
>
On Mon, 31 Oct 2022 12:25:43 GMT, Claes Redestad wrote:
>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3484:
>>
>>> 3482: decrementl(index);
>>> 3483: jmpb(LONG_SCALAR_LOOP_BEGIN);
>>> 3484: bind(LONG_SCALAR_LOOP_END);
>>
>> You can share this loop with the scalar ones above.
>
> T
On Thu, 10 Nov 2022 15:03:26 GMT, Claes Redestad wrote:
>> Continuing the work initiated by @luhenry to unroll and then intrinsify
>> polynomial hash loops.
>>
>> I've rewired the library changes to route via a single `@IntrinsicCandidate`
>> method. To make this work I've harmonized how they
On Mon, 7 Nov 2022 14:24:18 GMT, Markus KARG wrote:
> @AlanBateman I fixed what you asked for. Kindly requesting review. :-)
I don't have any other comments. @bplb told me that he would sponsor this for
you.
-
PR: https://git.openjdk.org/jdk/pull/10999
On Fri, 4 Nov 2022 18:13:23 GMT, Lance Andersen wrote:
> Please review the following PR which updates several of the ZipInputStream
> methods whose javadoc is inherited to clarify the methods are acting on the
> current ZIP Entry.
>
> There are no changes in behavior. The main description f
On Fri, 11 Nov 2022 11:45:43 GMT, Lance Andersen wrote:
> It would probably be easier for the reviewers and for you if the PR could be
> broken out by areas into separate PRs
Leaving out the non-public and non-exported classes would also reduce the PR
size.
-
PR: https://git.open
On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote:
> Please review a "somewhat automated" change to insert `@spec` tags into doc
> comments, as appropriate, to leverage the recent new javadoc feature to
> generate a new page listing the references to all external specifications
> listed
On Thu, 10 Nov 2022 21:56:26 GMT, Jonathan Gibbons wrote:
> On the same text but linking to different RFCs: that's tantamount to a bug
> somewhere. The spec for `@spec` dictates that the URLs and titles should be
> in 1-1 correspondence, and this is supposed to be enforced in the docket. In
>
31 matches
Mail list logo
