Log4j 2 supports the notion of a PreciseClock - one that can be initialized to
something more precise than a millisecond. At the same time it also supports
running with no heap allocations in certain circumstances. I am in the process
of moving our master branch to require Java 11 as the
On Fri, 2 Apr 2021 10:52:45 GMT, Doug Lea wrote:
> This reinserts setting common pool parallelism inadvertently clobbered in
> JDK-8259800
This pull request has now been integrated.
Changeset: cec66cf8
Author:Doug Lea
URL: https://git.openjdk.java.net/jdk/commit/cec66cf8
Stats:
On Fri, 2 Apr 2021 21:45:58 GMT, Brian Burkhalter wrote:
> This test emits to a `java.io.ByteArrayOutputStream` the contents of a
> `java.utils.prefs.Preferences` node. The `UTF-8` character encoding is used
> [1]. The `ByteArrayOutputStream` is then converted to a `String` using
>
This test emits to a `java.io.ByteArrayOutputStream` the contents of a
`java.utils.prefs.Preferences` node. The `UTF-8` character encoding is used
[1]. The `ByteArrayOutputStream` is then converted to a `String` using
`toString()` which uses the platform's default character set [2]. The
On Fri, 2 Apr 2021 15:48:50 GMT, Ian Graves wrote:
>> Bug fix with the intersection `&&` operator in regex patterns. In
>> JDK-8037397, some character classes on the right hand side of the operator
>> are dropped in cases where nested `[..]` classes are used with non "nested"
>> ones.
>
> Ian
> Bug fix with the intersection `&&` operator in regex patterns. In
> JDK-8037397, some character classes on the right hand side of the operator
> are dropped in cases where nested `[..]` classes are used with non "nested"
> ones.
Ian Graves has updated the pull request incrementally with one
On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote:
> 8264148: Update spec for exceptions retrofitted for exception chaining
Joe,
The Serviceability part looks good.
Thanks,
Serguei
-
PR: https://git.openjdk.java.net/jdk/pull/3182
On Thu, 1 Apr 2021 03:24:04 GMT, Naoto Sato wrote:
> Please review the fix to the subject issue. Thanks to the contribution by
> Chris Johnson.
This pull request has now been integrated.
Changeset: 6c145c47
Author:Naoto Sato
URL: https://git.openjdk.java.net/jdk/commit/6c145c47
On Thu, 1 Apr 2021 00:33:26 GMT, Florent Guillaume
wrote:
>> Ian Graves has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Adding a test.
>
> src/java.base/share/classes/java/util/regex/Pattern.java line 2666:
>
>> 2664:
> Bug fix with the intersection `&&` operator in regex patterns. In
> JDK-8037397, some character classes on the right hand side of the operator
> are dropped in cases where nested `[..]` classes are used with non "nested"
> ones.
Ian Graves has updated the pull request incrementally with one
On Thu, 1 Apr 2021 14:21:20 GMT, Roger Riggs wrote:
>> Ian Graves has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Adding a test.
>
> Please add a test.
Tagging with CSR because this will impact a long-standing (buggy) behavior.
On Fri, 2 Apr 2021 14:41:06 GMT, Jorn Vernee wrote:
>> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
>> line 874:
>>
>>> 872: case NEW_ARRAY:
>>> 873: Class rtype =
>>> name.function.methodType().returnType();
>>> 874:
On Fri, 2 Apr 2021 13:56:31 GMT, Vladimir Ivanov wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> - Address review comments
>> - Use cached version of store func getter
>> - Use ARRAY_STORE intrinsic for array
On Fri, 2 Apr 2021 13:17:55 GMT, Jorn Vernee wrote:
>> This patch speeds up MethodHandle.asCollector handles where the array type
>> is not Object[], as well as speeding up all collectors where the arity is
>> greater than 10.
>>
>> The old code is creating a collector handle by combining a
On Fri, 2 Apr 2021 13:20:44 GMT, Alan Bateman wrote:
>> This reinserts setting common pool parallelism inadvertently clobbered in
>> JDK-8259800
>
> This looks okay to me, I just wonder if we should have a test to the value of
> getCommonPoolParallelism.
We once had a test, but now that
On Thu, 1 Apr 2021 19:19:10 GMT, Paul Sandoz wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> - Address review comments
>> - Use cached version of store func getter
>> - Use ARRAY_STORE intrinsic for array
On Fri, 2 Apr 2021 10:52:45 GMT, Doug Lea wrote:
> This reinserts setting common pool parallelism inadvertently clobbered in
> JDK-8259800
This looks okay to me, I just wonder if we should have a test to the value of
getCommonPoolParallelism.
-
Marked as reviewed by alanb
> This patch speeds up MethodHandle.asCollector handles where the array type is
> not Object[], as well as speeding up all collectors where the arity is
> greater than 10.
>
> The old code is creating a collector handle by combining a set of hard coded
> methods for collecting arguments into
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
This reinserts setting common pool parallelism inadvertently clobbered in
JDK-8259800
-
Commit messages:
- Reinsert omitted assignment
- Reinsert omitted assignment
Changes: https://git.openjdk.java.net/jdk/pull/3324/files
Webrev:
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
On Thu, 1 Apr 2021 15:55:59 GMT, Jaroslav Bachorik
wrote:
>>> Does each getter call result in parsing /proc, or do things aggregated over
>>> several calls or hooks?
>>
>> From the looks of it the event emitting code uses `Metrics.java` interface
>> for retrieving the info. Each call to a
On Fri, 2 Apr 2021 03:10:57 GMT, Dong Bo wrote:
>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic
>> idea can be found at
>> http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
On Fri, 2 Apr 2021 07:05:26 GMT, Dong Bo wrote:
> PING... Any suggestions on the updated commit?
Once you reply to the comments, sure.
-
PR: https://git.openjdk.java.net/jdk/pull/3228
On Fri, 26 Mar 2021 01:50:33 GMT, Xiaohong Gong wrote:
> Currently "VectorMask.andNot()" is not vectorized:
> public VectorMask andNot(VectorMask m) {
> // FIXME: Generate good code here.
> return bOp(m, (i, a, b) -> a && !b);
> }
> This can be implemented with`
On Thu, 1 Apr 2021 03:39:43 GMT, Xiaohong Gong wrote:
>> Currently "VectorMask.andNot()" is not vectorized:
>> public VectorMask andNot(VectorMask m) {
>> // FIXME: Generate good code here.
>> return bOp(m, (i, a, b) -> a && !b);
>> }
>> This can be implemented with`
On Fri, 2 Apr 2021 09:59:31 GMT, Ningsheng Jian wrote:
>> Xiaohong Gong has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move the changing to AbstractMask.andNot and revert changes in VectorMask
>>
>> Change-Id:
On Wed, 24 Mar 2021 10:25:44 GMT, Lance Andersen wrote:
>> Hi Lance，
>> Thanks a lot for your review. I will update the PR ASAP.
>> May I ask your help to also review the CSR？ Thanks!
>>
>> BRs,
>> Lin
>
> Hi Lin,
>
> On Mar 24, 2021, at 2:51 AM, Lin Zang ***@***.**@***.***>> wrote:
>
>
> 4890732: GZIPOutputStream doesn't support optional GZIP fields
Lin Zang has updated the pull request incrementally with one additional commit
since the last revision:
add class GZIPHeaderData, refine testcases
-
Changes:
- all:
On Mon, 29 Mar 2021 03:28:54 GMT, Dong Bo wrote:
> > Please consider losing the non-SIMD case. It doesn't result in any
> > significant gain.
>
> The non-SIMD case is useful for MIME decoding performance.
Your test results suggest that it isn't useful for that, surely?
-
PR:
On Fri, 2 Apr 2021 03:10:57 GMT, Dong Bo wrote:
>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic
>> idea can be found at
>> http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
On Fri, 2 Apr 2021 03:10:57 GMT, Dong Bo wrote:
>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic
>> idea can be found at
>> http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
On Thu, 1 Apr 2021 03:24:04 GMT, Naoto Sato wrote:
> Please review the fix to the subject issue. Thanks to the contribution by
> Chris Johnson.
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3300
On Thu, 1 Apr 2021 18:48:15 GMT, Jim Laskey wrote:
>> src/java.base/share/native/libjimage/imageFile.cpp line 219:
>>
>>> 217: // WARNING: Should never close the jimage file.
>>> 218: // Threads may still be running at shutdown.
>>> 219: #if 0
>>
>> Are you keeping the code in order
On Thu, 1 Apr 2021 11:48:21 GMT, Jim Laskey wrote:
> We should never close the jimage since java threads can still be running
> after a hard exit().
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3304
On Tue, 30 Mar 2021 03:24:16 GMT, Dong Bo wrote:
>>> I think I can rewrite this part as loops.
>>> With an intial implemention, we can have almost half of the code size
>>> reduced (1312B -> 748B). Sounds OK to you?
>>
>> Sounds great, but I'm still somewhat concerned that the non-SIMD case
37 matches
Mail list logo
