On Sun, 10 Jan 2021 01:59:18 GMT, Brett Okken
wrote:
>> Philippe Marschall has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add unit tests
>>
>> - add unit test for Reader#read(CharBuffer)
>> - add unit test for InputStreamReader#
On Sat, 16 Jan 2021 00:48:43 GMT, Naoto Sato wrote:
>> Actually I was correcting the L217, changed {) -> {}. But 2 days ago,
>> Jonathan Gibbons fixed it in another commit 6bb6093. I found his fix after
>> running the merge. Looks both of us forgot to update the copyright year. Any
>> suggesti
> This is the changes for JDK 16 msg drop 10.
Leo Jiang has updated the pull request incrementally with one additional commit
since the last revision:
fix the missing copyright year for standard.properties
-
Changes:
- all: https://git.openjdk.java.net/jdk16/pull/123/files
-
> 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 Sun, 17 Jan 2021 15:51:58 GMT, Peter Levart wrote:
> `newStringUTF8NoRepl()` does not contain this optimization.
Good catch: this optimization was in the original code for `newStringNoRepl`
but not `newStringUTF8NoRepl`. I'll put it back to avoid a regression, but this
time into `newStr
JDK-8013527[1] has somehow become the umbrella bug for "Using
MethodHandles to call caller sensitive methods leads to interesting
results".
To recap: A caller sensitive method knows about who called it, and can
behave differently when called from an other context.
Examples are: Class.forName,
8252412: [macos11] File-based loading of dynamic libraries deprecated
-
Commit messages:
- JDK-8252412: [macos11] File-based loading of dynamic libraries deprecated
Changes: https://git.openjdk.java.net/jdk/pull/2119/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2119&
On Sun, 17 Jan 2021 18:39:55 GMT, Martin Buchholz wrote:
> 8259796: timed CompletableFuture.get may swallow InterruptedException
Marked as reviewed by dl (Reviewer).
-
PR: https://git.openjdk.java.net/jdk16/pull/126
8259796: timed CompletableFuture.get may swallow InterruptedException
-
Commit messages:
- JDK-8259796
Changes: https://git.openjdk.java.net/jdk16/pull/126/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=126&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8
On 05.01.21 01:53, Brian Burkhalter wrote:
On Thu, 31 Dec 2020 10:11:58 GMT, Philippe Marschall
wrote:
...
How does the performance of `InputStreamReader.read(CharBuffer)` compare for
the case where only the change to `Reader` is made versus if all your proposed
changes are applied?
I l
On Sun, 17 Jan 2021 14:56:40 GMT, Peter Levart wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Simplify lookupCharset
>
> This looks good.
> Are you planning to do similar things for encoding too?
I already appr
On Sun, 17 Jan 2021 12:07:03 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
>> over
On 17/01/2021 10:58 pm, David Holmes wrote:
On Fri, 15 Jan 2021 23:50:16 GMT, Alex Menkov wrote:
The fix adds NMT handling for non-java launchers
Alex,
This approach results in two scans of the argument list in the IsJavaArgs case.
I don't know if we care about startup in the non-Java laun
On Fri, 15 Jan 2021 23:50:16 GMT, Alex Menkov wrote:
> The fix adds NMT handling for non-java launchers
Alex,
This approach results in two scans of the argument list in the IsJavaArgs case.
I don't know if we care about startup in the non-Java launchers, but this will
likely affect it.
David
On Sun, 17 Jan 2021 09:21:27 GMT, Peter Levart wrote:
>> This looks much better now. Maybe just one small suggestion:
>> `java.lang.StringCoding#lookupCharset` is used in two places and in both
>> places the same exception handling/rethrowing logic is wrapped around the
>> invocation. So you c
> 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 Sun, 17 Jan 2021 09:03:30 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
On Sat, 16 Jan 2021 01:02:20 GMT, Claes Redestad wrote:
>> Some common logic is now extracted into methods. That's good. But much of
>> the decoding logic still remains in String. I still think all of static
>> methods can be moved to StringCoding directly as they are now while the
>> private
18 matches
Mail list logo
