On Fri, 15 Jan 2021 23:50:16 GMT, Alex Menkov wrote:
> The fix adds NMT handling for non-java launchers
Looks good
-
Marked as reviewed by zgu (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/2106
On Sat, 16 Jan 2021 00:25:24 GMT, Peter Levart wrote:
> Do you think this code belongs more to String than to StringCoding?
I consider StringCoding an implementation detail of String, so I'm not sure
there's (much) value in maintaining the separation of concern if it is cause
for a
> The `StringCoding.resultCached` mechanism is used to remove the allocation of
> a `StringCoding.Result` object on potentially hot paths used in some `String`
> constructors. Using a `ThreadLocal` has overheads though, and the overhead
> got a bit worse after JDK-8258596 which addresses a leak
On Thu, 7 Jan 2021 16:40:26 GMT, Andy Herrick wrote:
> JDK-8259238: Clean up Log.java and remove usage of non-final static variables.
Marked as reviewed by kizune (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/1977
On Mon, 11 Jan 2021 17:42:21 GMT, Andy Herrick wrote:
> JDK-8258755: jpackage: Invalid 32-bit exe when building app-image
Marked as reviewed by kizune (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/2030
On Wed, 6 Jan 2021 15:52:07 GMT, Andy Herrick wrote:
> JDK-8259062: Remove MacAppStoreBundler
Marked as reviewed by kizune (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/1962
On Fri, 15 Jan 2021 01:59:07 GMT, Leo Jiang wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
>> line 518:
>>
>>> 516: doclet.footer_specified=\
>>> 517: The -footer option is no longer supported and will be ignored.\n\
>>> 518:
On Fri, 15 Jan 2021 22:03:31 GMT, Claes Redestad wrote:
>> Hi Claes,
>> This is quite an undertaking in re-factoring!
>> I think that decoding logic that you produced can still be kept in
>> StringCoding class though. The private constructor that you created for
>> UTF-8 decoding is
On Fri, 15 Jan 2021 23:36:35 GMT, Claes Redestad wrote:
>> - The MD5 intrinsics added by
>> [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that
>> the `int[] x` isn't actually needed. This also applies to the SHA intrinsics
>> from which the MD5 intrinsic takes
The fix adds NMT handling for non-java launchers
-
Commit messages:
- Handle NMT for non-java launchers
Changes: https://git.openjdk.java.net/jdk/pull/2106/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2106=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8258917
On Fri, 15 Jan 2021 23:50:16 GMT, Alex Menkov wrote:
> The fix adds NMT handling for non-java launchers
Added serviceability as serviceability tools use launcher functionality
-
PR: https://git.openjdk.java.net/jdk/pull/2106
> The `StringCoding.resultCached` mechanism is used to remove the allocation of
> a `StringCoding.Result` object on potentially hot paths used in some `String`
> constructors. Using a `ThreadLocal` has overheads though, and the overhead
> got a bit worse after JDK-8258596 which addresses a leak
> - The MD5 intrinsics added by
> [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that
> the `int[] x` isn't actually needed. This also applies to the SHA intrinsics
> from which the MD5 intrinsic takes inspiration
> - Using VarHandles we can simplify the code in
On Fri, 15 Jan 2021 23:21:00 GMT, Valerie Peng wrote:
>> Claes Redestad 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
>>
On Sun, 20 Dec 2020 20:27:03 GMT, Claes Redestad wrote:
> - The MD5 intrinsics added by
> [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that
> the `int[] x` isn't actually needed. This also applies to the SHA intrinsics
> from which the MD5 intrinsic takes inspiration
On Fri, 15 Jan 2021 22:54:32 GMT, Valerie Peng wrote:
>> - The MD5 intrinsics added by
>> [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that
>> the `int[] x` isn't actually needed. This also applies to the SHA intrinsics
>> from which the MD5 intrinsic takes
On Sun, 20 Dec 2020 20:27:03 GMT, Claes Redestad wrote:
> - The MD5 intrinsics added by
> [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that
> the `int[] x` isn't actually needed. This also applies to the SHA intrinsics
> from which the MD5 intrinsic takes inspiration
On Fri, 15 Jan 2021 21:39:00 GMT, Peter Levart wrote:
> WDYT?
I get that the approach I took got a bit messy, but I've just spent some time
cleaning it up. Please have a look at the latest, which outlines much of the
logic and consolidates the replace/throw logic in the UTF8 decode paths.
> The `StringCoding.resultCached` mechanism is used to remove the allocation of
> a `StringCoding.Result` object on potentially hot paths used in some `String`
> constructors. Using a `ThreadLocal` has overheads though, and the overhead
> got a bit worse after JDK-8258596 which addresses a leak
On Fri, 15 Jan 2021 19:14:06 GMT, Naoto Sato wrote:
>> The `StringCoding.resultCached` mechanism is used to remove the allocation
>> of a `StringCoding.Result` object on potentially hot paths used in some
>> `String` constructors. Using a `ThreadLocal` has overheads though, and the
>>
On Fri, 15 Jan 2021 20:05:17 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/lang/String.java line 544:
>>
>>> 542: return;
>>> 543: }
>>> 544: if (charset == UTF_8) {
>>
>> The constructor is getting big. Might be better to keep the original private
On Fri, 15 Jan 2021 20:14:48 GMT, Roger Riggs wrote:
>> Since we're calculating two final values, that split was what necessitated a
>> `Result` object. Until valhalla I don't think there's a way to get rid of
>> the performance cost here without putting the bulk of the logic into the
>>
On Fri, 15 Jan 2021 19:11:38 GMT, Naoto Sato wrote:
>> The `StringCoding.resultCached` mechanism is used to remove the allocation
>> of a `StringCoding.Result` object on potentially hot paths used in some
>> `String` constructors. Using a `ThreadLocal` has overheads though, and the
>>
On Fri, 15 Jan 2021 14:33:19 GMT, Claes Redestad wrote:
> The `StringCoding.resultCached` mechanism is used to remove the allocation of
> a `StringCoding.Result` object on potentially hot paths used in some `String`
> constructors. Using a `ThreadLocal` has overheads though, and the overhead
On Mon, 4 Jan 2021 18:11:05 GMT, Kiran Sidhartha Ravikumar
wrote:
> Hi Guys,
>
> Updating the summary as tzdata2020f is available and includes tzdata2020e
> changes also.
>
> Please review the integration of tzdata2020f to JDK.
>
> Details regarding the change can be viewed at -
>
On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote:
>> This PR is not stale; it's just still waiting for input from @AlanBateman.
>
> @magicus Can the CharacterDataXXX.template files move to
> src/java.base/share/classes/java/lang?
@AlanBateman That sounds like an excellent idea. I'll update
2020/12/4 6:08:13 -0800, er...@openjdk.java.net:
> On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman wrote:
>>> And I can certainly move jdwp.spec to java.base instead. That's the
>>> reason I need input on this: All I know is that is definitely not
>>> the responsibility of the Build Group to
On Fri, 15 Jan 2021 16:49:57 GMT, Roger Riggs wrote:
> Interesting, I was/am in the middle of converting Result to be a Valhalla
> primitive class to reduce the memory pressure and had written some new jmh
> tests too.
> And to reduce the dependency on ThreadLocals.
Ok, I expect that would
On Mon, 14 Dec 2020 12:13:23 GMT, Сергей Цыпанов
wrote:
> Hello, I feel like this was previously discussed in
> https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot
> find original mail I post this here.
>
> Currently `Collections.addAll()` is implemented and documented
On Thu, 14 Jan 2021 22:38:53 GMT, Peter Levart 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 10 additional
>>
On Fri, 15 Jan 2021 10:24:24 GMT, Kiran Sidhartha Ravikumar
wrote:
>> Hi Guys,
>>
>> Updating the summary as tzdata2020f is available and includes tzdata2020e
>> changes also.
>>
>> Please review the integration of tzdata2020f to JDK.
>>
>> Details regarding the change can be viewed at -
On Fri, 15 Jan 2021 14:33:19 GMT, Claes Redestad wrote:
> The `StringCoding.resultCached` mechanism is used to remove the allocation of
> a `StringCoding.Result` object on potentially hot paths used in some `String`
> constructors. Using a `ThreadLocal` has overheads though, and the overhead
> 1. Replace ` ` with a normal space, that should work as well and is easier
> to read
Looks like my e-mail client was so kind and replaced the HTML character
reference. It should have said:
"Replace `& nbsp ;` with a normal space, ..."
Additionally, if you want to search for projects using
On 15/01/2021 10:51, Tommy Ludwig wrote:
Parsing the delegate toString would be a usable workaround for the time being
for Micrometer, assuming the format is stable across JDK versions. It's better
than no alternative, which is where I think we are currently at for the wrapped
cases.
As a
The following probably does not matter much because I am not an OpenJDK
contributor, but personally
I think throwing an UnsupportedOperationException is reasonable:
1. It is consistent with the other methods which also only work for one
specific variant
2. Code which calls UUID.version() on
The `StringCoding.resultCached` mechanism is used to remove the allocation of a
`StringCoding.Result` object on potentially hot paths used in some `String`
constructors. Using a `ThreadLocal` has overheads though, and the overhead got
a bit worse after JDK-8258596 which addresses a leak by
On Mon, 11 Jan 2021 09:20:07 GMT, Magnus Ihse Bursie wrote:
>> Marked as reviewed by prr (Reviewer).
>
> This PR is not stale; it's just still waiting for input from @AlanBateman.
@magicus Can the CharacterDataXXX.template files move to
src/java.base/share/classes/java/lang?
-
Parsing the delegate toString would be a usable workaround for the time being
for Micrometer, assuming the format is stable across JDK versions. It's better
than no alternative, which is where I think we are currently at for the wrapped
cases.
On 2021/01/09 1:24, "Doug Lea" wrote:
On
On Mon, 4 Jan 2021 18:40:06 GMT, Naoto Sato wrote:
> Looks good.
> IIUC, 2020f is already out, and the 2020e-2020f diff does not seem to include
> any data change. Would you change this PR to incorporate 2020f?
Hi @naotoj ,
I have updated the VERSION and PR title to incorporate tzdata2020f,
> Hi Guys,
>
> Please review the integration of tzdata2020e to JDK.
>
> Details regarding the change can be viewed at -
> https://mm.icann.org/pipermail/tz-announce/2020-December/63.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8258878
>
> Most of the changes are about correcting
40 matches
Mail list logo
