On Thu, 29 Oct 2020 00:59:56 GMT, Jason Tatton
wrote:
>> Please review the improvements which I have made to the
>> java/lang/StringIndexOfChar.java jmh benchmark. Please let me know if any
>> further improvements are required.
>>
>> Thanks,
>> Jason
>
> Jason Tatton has updated the pull requ
> Please review the improvements which I have made to the
> java/lang/StringIndexOfChar.java jmh benchmark. Please let me know if any
> further improvements are required.
>
> Thanks,
> Jason
Jason Tatton has updated the pull request incrementally with one additional
commit since the last revis
On Wed, 28 Oct 2020 22:44:37 GMT, Claes Redestad wrote:
>> Jason Tatton has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Adjusted benchmark to use BlackHole and improved String array syntax as
>> advised
>
> test/micro/org/openjdk/bench/
On Wed, 28 Oct 2020 21:59:53 GMT, Jason Tatton
wrote:
> Please review the improvements which I have made to the
> java/lang/StringIndexOfChar.java jmh benchmark. Please let me know if any
> further improvements are required.
>
> Thanks,
> Jason
Looks OK.
FWIW the current looping scheme look
On Wed, 28 Oct 2020 20:50:49 GMT, Claes Redestad wrote:
> A microbenchmark with --enable-preview was added in JDK-8248135. This had the
> unintended side effect that we now had to always run with --enable-preview.
>
> With records out of preview, I think the best course of action now is to not
On Wed, 28 Oct 2020 20:56:55 GMT, Eric Caspole wrote:
>> A microbenchmark with --enable-preview was added in JDK-8248135. This had
>> the unintended side effect that we now had to always run with
>> --enable-preview.
>>
>> With records out of preview, I think the best course of action now is
On Wed, 28 Oct 2020 20:50:49 GMT, Claes Redestad wrote:
> A microbenchmark with --enable-preview was added in JDK-8248135. This had the
> unintended side effect that we now had to always run with --enable-preview.
>
> With records out of preview, I think the best course of action now is to not
Please review the improvements which I have made to the
java/lang/StringIndexOfChar.java jmh benchmark. Please let me know if any
further improvements are required.
Thanks,
Jason
-
Commit messages:
- 8254782
Changes: https://git.openjdk.java.net/jdk/pull/918/files
Webrev: https:
I regret adding the `directsign` property/option to JarSigner/jarsigner. See
the bug for details.
-
Commit messages:
- 8255536: Remove the directsign property and option
Changes: https://git.openjdk.java.net/jdk/pull/915/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=
A microbenchmark with --enable-preview was added in JDK-8248135. This had the
unintended side effect that we now had to always run with --enable-preview.
With records out of preview, I think the best course of action now is to not
build the micros with preview enabled, and leave it for a future
On Wed, 28 Oct 2020 20:50:49 GMT, Claes Redestad wrote:
> A microbenchmark with --enable-preview was added in JDK-8248135. This had the
> unintended side effect that we now had to always run with --enable-preview.
>
> With records out of preview, I think the best course of action now is to not
On Wed, 28 Oct 2020 19:28:36 GMT, Mandy Chung wrote:
>> Hi Mandy and Peter,
>> reading your exchanges, i wonder if it's not better to stop trying to add
>> more and more features to the already clunky java.lang.reflect.Proxy but
>> instead to move to provide the same set of feature but using an
On Wed, 28 Oct 2020 17:35:16 GMT, Naoto Sato wrote:
> Hi,
>
> Please review this simple doc fix in
> DateTimeFormatterBuilder.appendPattern(). It is missing the value for
> `maxWidth` argument.
>
> Naoto
This pull request has now been integrated.
Changeset: 790d6e2d
Author:Naoto Sato
U
Daniel,
https://bugs.openjdk.java.net/browse/JDK-8240111 has been updated with
the evaluation of your request. Please take a look.
- Alexey
On 2/27/2020 2:00 AM, Daniel Peintner wrote:
Alexey, all,
In my case the update, as described, seems to work just fine. However
once I try to actually
On Wed, 28 Oct 2020 18:01:44 GMT, Rémi Forax
wrote:
>>> Yes, but it is not really useful there. The super handler is captured by
>>> the user invocation handler created in the invocation handler factory
>>> function and it is only used by the user invocation handler. All we need in
>>> the pr
On Mon, 12 Oct 2020 13:24:16 GMT, Severin Gehwolf wrote:
> Test only change. With
> [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has
> been added on the hotspot side, but nothing for the Java Metrics code. Same
> for [JDK-8252359](https://bugs.openjdk.java.net/browse/
On Wed, 28 Oct 2020 17:35:16 GMT, Naoto Sato wrote:
> Hi,
>
> Please review this simple doc fix in
> DateTimeFormatterBuilder.appendPattern(). It is missing the value for
> `maxWidth` argument.
>
> Naoto
Marked as reviewed by rriggs (Reviewer).
-
PR: https://git.openjdk.java.ne
On Wed, 28 Oct 2020 17:36:40 GMT, Mandy Chung wrote:
>>> Hi Peter,
>>>
>>> > Question remains how do we distinguish proxies with old-fassioned
>>> > InvocationHandlers from proxies with InvocationHandlers having access to
>>> > super-default-handler. Both kinds of handlers look the same from P
On Wed, 28 Oct 2020 17:35:16 GMT, Naoto Sato wrote:
> Hi,
>
> Please review this simple doc fix in
> DateTimeFormatterBuilder.appendPattern(). It is missing the value for
> `maxWidth` argument.
>
> Naoto
Looks good
-
Marked as reviewed by lancea (Reviewer).
PR: https://git.ope
Hi,
Please review this simple doc fix in DateTimeFormatterBuilder.appendPattern().
It is missing the value for `maxWidth` argument.
Naoto
-
Commit messages:
- 8255533: Incorrect javadoc in DateTimeFormatterBuilder.appendPattern() for
'uu'/'yy'
Changes: https://git.openjdk.java.n
On Wed, 28 Oct 2020 08:35:47 GMT, Peter Levart wrote:
> Yes, but it is not really useful there. The super handler is captured by the
> user invocation handler created in the invocation handler factory function
> and it is only used by the user invocation handler. All we need in the proxy
> ins
On Wed, 28 Oct 2020 15:42:37 GMT, Bob Vandette wrote:
>> Severin Gehwolf 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 one additional
>> commi
Hi Mike,
As you said, creating a bug report would be a good start. If it involves
a signature change, it'd need to go through a proper review (CSR) process.
When you are ready to submit a bug report, please make sure to add a
test case to illustrate the use case scenario.
Thanks,
Joe
On 10
On Wed, 28 Oct 2020 15:00:59 GMT, Jorn Vernee wrote:
>> Hi,
>>
>> Currently, if MethodHandles::permuteArguments is used with a reorder array
>> that is the wrong size, or one of the indexes in it is out of bounds of the
>> new type, we simply get the exception message:
>>
>> bad reorder a
On Wed, 21 Oct 2020 02:28:30 GMT, Kim Barrett wrote:
>> Finally returning to this review that was started in April 2020. I've
>> recast it as a github PR. I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-A
On Wed, 28 Oct 2020 13:49:53 GMT, Severin Gehwolf wrote:
>> Test only change. With
>> [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has
>> been added on the hotspot side, but nothing for the Java Metrics code. Same
>> for [JDK-8252359](https://bugs.openjdk.java.net/bro
On Wed, 28 Oct 2020 14:30:30 GMT, Chris Hegarty wrote:
>> I've added some negative tests that test for the different failure
>> conditions.
>
> Thanks for adding additional test coverage @JornVernee.
>
> Writing a tight implementation of assertThrows is non-trivial - I'm not sure
> that the ve
> Hi,
>
> Currently, if MethodHandles::permuteArguments is used with a reorder array
> that is the wrong size, or one of the indexes in it is out of bounds of the
> new type, we simply get the exception message:
>
> bad reorder array [...]
>
> I think we can improve the exception message b
On Wed, 28 Oct 2020 14:57:44 GMT, Jorn Vernee wrote:
>> Hi,
>>
>> Currently, if MethodHandles::permuteArguments is used with a reorder array
>> that is the wrong size, or one of the indexes in it is out of bounds of the
>> new type, we simply get the exception message:
>>
>> bad reorder a
On Wed, 28 Oct 2020 13:32:19 GMT, Jorn Vernee wrote:
>>>
>>>
>>> Seems like a reasonable change. Is there an already existing test for "bad"
>>> permute args that could be expanded to discern the new exception message?
>>
>> There are several tests for permuteArguments, but none that explicit
> Test only change. With
> [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has
> been added on the hotspot side, but nothing for the Java Metrics code. Same
> for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359).
>
> When JDK-8217766 got fixed cgroup factor
On Wed, 28 Oct 2020 11:52:17 GMT, Jorn Vernee wrote:
>> Seems like a reasonable change. Is there an already existing test for "bad"
>> permute args that could be expanded to discern the new exception message?
>
>>
>>
>> Seems like a reasonable change. Is there an already existing test for "bad
> Hi,
>
> Currently, if MethodHandles::permuteArguments is used with a reorder array
> that is the wrong size, or one of the indexes in it is out of bounds of the
> new type, we simply get the exception message:
>
> bad reorder array [...]
>
> I think we can improve the exception message b
On Wed, 28 Oct 2020 08:56:05 GMT, Сергей Цыпанов
wrote:
>> FYI it is better to use merge, instead of rebase+force push. Rebase breaks
>> history and all existed code comments.
>
> @mrserb thanks for pointing this out!
Thanks for updating with latest master changes Sergey! My tests were all gre
Hi everyone,
I'm working on a project that makes use of the StAX API and an issue I have
encountered is that when wrapping an `XMLStreamReader` with a
`StreamFilter`, errors encountered in the setup are not thrown to the
caller. The source of the error could be any stream error that is triggered
as
On Thu, 22 Oct 2020 20:46:15 GMT, Сергей Цыпанов
wrote:
> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
> reason to explicitly instantiate any instance of `Atomic*` class with its
> default value, i.e. `new AtomicInteger(0)` could be replaced with `new
> AtomicInteg
On Wed, 28 Oct 2020 09:20:54 GMT, Aleksey Shipilev wrote:
>
>
> This looks okay to me. Someone from core-libs should take a look as well.
>
> As the follow-up, maybe reconcile that method returns normally only with
> `true`, and throws exceptions otherwise. There are some uses like
> `assert
On Mon, 26 Oct 2020 09:19:45 GMT, Dong Bo wrote:
> BigInteger.shiftRightImplWorker and BigInteger.shiftLeftImplWorker are not
> intrinsified on aarch64, which have been done on x86_64.
> We can implement them via USHL NEON instruction (register), which handles
> four integers one time at most,
On Tue, 27 Oct 2020 16:45:42 GMT, Andrew Haley wrote:
>> Dong Bo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> minor improvements for small BigIntegers
>
> Marked as reviewed by aph (Reviewer).
@theRealAph Thanks for the review.
@Rea
On Wed, 28 Oct 2020 10:19:58 GMT, Chris Hegarty wrote:
>
>
> Seems like a reasonable change. Is there an already existing test for "bad"
> permute args that could be expanded to discern the new exception message?
There are several tests for permuteArguments, but none that explicitly test
thi
On Wed, 28 Oct 2020 09:20:54 GMT, Aleksey Shipilev wrote:
>> Hi,
>>
>> Currently, if MethodHandles::permuteArguments is used with a reorder array
>> that is the wrong size, or one of the indexes in it is out of bounds of the
>> new type, we simply get the exception message:
>>
>> bad reor
On Wed, 28 Oct 2020 08:54:31 GMT, Peter Levart wrote:
>> Some thoughts regarding the parameter type of refersTo. Summary: I think
>> `refersTo(T)` is fine and that we don't want to change it to
>> `refersTo(Object)`.
>>
>> I don't think we have a migration issue similar to generifying collecti
On Fri, 23 Oct 2020 15:51:47 GMT, Severin Gehwolf wrote:
>> Test only change. With
>> [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has
>> been added on the hotspot side, but nothing for the Java Metrics code. Same
>> for [JDK-8252359](https://bugs.openjdk.java.net/bro
On 28/10/2020 03:30, Dong Bo wrote:
> My bad, it should be cbnz(numIter, ShiftOneLoop).
> But it's gone now, the ShiftOneLoop is unrolled in the newest version.
> Do you think we need further modifications?
No. As I said in my previous reply, the cost of actually shifting
is now only 5% of a bench
On Tue, 27 Oct 2020 12:43:47 GMT, Jorn Vernee wrote:
> Hi,
>
> Currently, if MethodHandles::permuteArguments is used with a reorder array
> that is the wrong size, or one of the indexes in it is out of bounds of the
> new type, we simply get the exception message:
>
> bad reorder array [.
On Wed, 28 Oct 2020 08:49:38 GMT, Sergey Bylokhov wrote:
>> Rebased onto master to have the fix introduced in
>> https://github.com/openjdk/jdk/pull/778
>
> FYI it is better to use merge, instead of rebase+force push. Rebase breaks
> history and all existed code comments.
@mrserb thanks for po
On Wed, 28 Oct 2020 03:46:55 GMT, Stuart Marks wrote:
> Some thoughts regarding the parameter type of refersTo. Summary: I think
> `refersTo(T)` is fine and that we don't want to change it to
> `refersTo(Object)`.
>
I agree that we don't have a migration problem here that collections had. So
On Wed, 28 Oct 2020 08:40:02 GMT, Сергей Цыпанов
wrote:
>> client changes are fine
>
> Rebased onto master to have the fix introduced in
> https://github.com/openjdk/jdk/pull/778
FYI it is better to use merge, instead of rebase+force push. Rebase breaks
history and all existed code comments.
On Sat, 24 Oct 2020 23:12:09 GMT, Phil Race wrote:
>> Сергей Цыпанов 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 one additional
>> commit si
On Wed, 28 Oct 2020 08:35:47 GMT, Peter Levart wrote:
>> Hi Peter,
>>
>>> Question remains how do we distinguish proxies with old-fassioned
>>> InvocationHandlers from proxies with InvocationHandlers having access to
>>> super-default-handler. Both kinds of handlers look the same from Proxy's
> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
> reason to explicitly instantiate any instance of `Atomic*` class with its
> default value, i.e. `new AtomicInteger(0)` could be replaced with `new
> AtomicInteger()` which is faster:
> @State(Scope.Thread)
> @OutputTime
On Wed, 28 Oct 2020 03:06:04 GMT, Mandy Chung wrote:
> Hi Peter,
>
> > Question remains how do we distinguish proxies with old-fassioned
> > InvocationHandlers from proxies with InvocationHandlers having access to
> > super-default-handler. Both kinds of handlers look the same from Proxy's
>
52 matches
Mail list logo
