On Mon, 21 Nov 2022 06:31:47 GMT, Jaikiran Pai wrote:
> While we are at it, would you be willing to change the member variables `e`
> to `private final` and the `in` to `private`? From what I can see, I don't
> see any other class accessing these package private fields.
Good catch, will do lat
On Sun, 20 Nov 2022 16:58:56 GMT, Markus KARG wrote:
>> Indeed my intention solely is to get rid of `Vector`, so I am fine with
>> keeping a low profile and being full backwards compatible. I assume SIS is
>> seldomly used, so opening a can of warms is not worth it (I think). I am
>> perfectly
On Fri, 18 Nov 2022 09:19:26 GMT, Matthias Baesken wrote:
> As discussed in https://bugs.openjdk.org/browse/JDK-8296945 , let us switch
> off VerifyDependencies in this test because of slow machines when
> (fast)debug builds are used, the test sometimes times out after the
> [JDK-8266074](htt
On Fri, 18 Nov 2022 09:19:26 GMT, Matthias Baesken wrote:
> As discussed in https://bugs.openjdk.org/browse/JDK-8296945 , let us switch
> off VerifyDependencies in this test because of slow machines when
> (fast)debug builds are used, the test sometimes times out after the
> [JDK-8266074](htt
On Fri, 18 Nov 2022 09:57:39 GMT, Alan Bateman wrote:
> JEP 436 proposes a second preview of Virtual Threads to allow time for more
> feedback and to get more experience with this feature. There is no change in
> direction, no API changes, and no bulk update of the implementation. For the
> im
On Fri, 18 Nov 2022 09:19:26 GMT, Matthias Baesken wrote:
> As discussed in https://bugs.openjdk.org/browse/JDK-8296945 , let us switch
> off VerifyDependencies in this test because of slow machines when
> (fast)debug builds are used, the test sometimes times out after the
> [JDK-8266074](htt
On Sun, 20 Nov 2022 17:41:28 GMT, Markus KARG wrote:
>> There is no need to use a temporary Vector within the constructor of
>> SynchronizedInputStream, as more efficient (non-synchronized) alternative
>> code (like List.of) will do the same in possibly less time. While the
>> optimization is
On Tue, 15 Nov 2022 06:33:00 GMT, Kim Barrett wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert to using simpler solution similar to the original 8274980
>
> src/hotspot/share/utilities/globalDefinitions.hpp
On Mon, 7 Nov 2022 20:40:33 GMT, Coleen Phillimore wrote:
>> This patch moves the acquisition of the boot class loader lock out of the
>> JVM and into the Java function.
>> Tested with tier1-4, and jvmti and jdi tests locally.
>
> Coleen Phillimore has updated the pull request incrementally with
On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons wrote:
> Please review an update for the troff man pages, following the recent update
> to upgrade to use pandoc 2.19.2
> (See https://bugs.openjdk.org/browse/JDK-8297165)
>
> In conjunction with this, one javadoc test also needs to be updated,
On Fri, 18 Nov 2022 11:44:32 GMT, Adam Sotona wrote:
> tools/launcher/ArgsFileTest.java was working because it didn't contain any
> test with --disable-@files option verifying VM really starts
What about the killswitch test ??
-
PR: https://git.openjdk.org/jdk/pull/11183
There are some modules like jdk.internal.le which contain no
publicly exported packages. In some of the experimentation we are doing, We
want to use the jdk.internal.org.jline.utils.Levenshtien class from
jdk.compiler.
Mechanically, we can do this without creating any new modules by adding a
quali
On Sun, 20 Nov 2022 15:37:24 GMT, Weijun Wang wrote:
> `codomain`, `VerifierCodeSource`, `isSigningRelated`, and `getUnsignedCS`
> also used nowhere.
Thanks. I think your `codomain` must mean `csdomain`.
-
PR: https://git.openjdk.org/jdk/pull/11072
> The cache named `signerToCodeSource` in `JarVerifier` is never used now.
pandaapo has updated the pull request incrementally with one additional commit
since the last revision:
Modify as review and update copyright.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/11072/fil
> There is no need to use a temporary Vector within the constructor of
> SynchronizedInputStream, as more efficient (non-synchronized) alternative
> code (like List.of) will do the same in possibly less time. While the
> optimization is not dramatic, it still makes sense to replace Vector unless
On Sun, 20 Nov 2022 16:49:16 GMT, Markus KARG wrote:
>>> @AlanBateman WDYT?
>>
>> The long standing and undocumented behavior is unfortunate. I don't think
>> the 1-arg constructor is fixable while still allowing for lazy behavior. So
>> I think the only thing we can do is document the existin
> There is no need to use a temporary Vector within the constructor of
> SynchronizedInputStream, as more efficient (non-synchronized) alternative
> code (like List.of) will do the same in possibly less time. While the
> optimization is not dramatic, it still makes sense to replace Vector unless
On Sun, 20 Nov 2022 15:21:31 GMT, Alan Bateman wrote:
>> @AlanBateman WDYT?
>
>> @AlanBateman WDYT?
>
> The long standing and undocumented behavior is unfortunate. I don't think the
> 1-arg constructor is fixable while still allowing for lazy behavior. So I
> think the only thing we can do is
> There is no need to use a temporary Vector within the constructor of
> SynchronizedInputStream, as more efficient (non-synchronized) alternative
> code (like List.of) will do the same in possibly less time. While the
> optimization is not dramatic, it still makes sense to replace Vector unless
On Wed, 9 Nov 2022 21:06:50 GMT, iaroslavski wrote:
>> Sorting:
>>
>> - adopt radix sort for sequential and parallel sorts on
>> int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single
>> element
>> - minor javado
On Sun, 20 Nov 2022 06:27:32 GMT, pandaapo wrote:
>> The cache named `signerToCodeSource` in `JarVerifier` is never used now.
>
> pandaapo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Modify as reviews.
`codomain`, `VerifierCodeSource`,
On Sun, 20 Nov 2022 13:06:40 GMT, Markus KARG wrote:
> @AlanBateman WDYT?
The long standing and undocumented behavior is unfortunate. I don't think the
1-arg constructor is fixable while still allowing for lazy behavior. So I think
the only thing we can do is document the existing behavior tha
On Sun, 20 Nov 2022 12:06:55 GMT, Markus KARG wrote:
>> The updated code now changes the behaviour in the other direction:
>>
>> In the original code, if `s2` was null a NPE was thrown in `peekNextStream`
>> when `s1` was exhausted.
>>
>> In the current code, `s2` is silently ignored if it is
On Sun, 20 Nov 2022 09:47:35 GMT, Jens Lidestrom wrote:
>> src/java.base/share/classes/java/io/SequenceInputStream.java line 82:
>>
>>> 80: * @param s2 the second input stream to read.
>>> 81: */
>>> 82: public SequenceInputStream(InputStream s1, InputStream s2) {
>>
>> BTW, w
On Sun, 20 Nov 2022 07:30:15 GMT, Alan Bateman wrote:
> > I might be mistaken, but that vector is not temporary: the vector and the
> > enumeration produced from it seems to be reachable for as long as the
> > stream is. Both the enumeration and the vector are synchronized. That
> > synchroniz
On Sun, 20 Nov 2022 09:14:32 GMT, Markus KARG wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> allowing s2 to be null
>
> src/java.base/share/classes/java/io/SequenceInputStream.java line 82:
>
>> 80: * @param
On Sun, 20 Nov 2022 07:30:15 GMT, Alan Bateman wrote:
> I might be mistaken, but that vector is not temporary: the vector and the
> enumeration produced from it seems to be reachable for as long as the stream
> is. Both the enumeration and the vector are synchronized. That
> synchronization mi
> Since JDK 18 some implementations of InputStream.transferTo, namely
> FileInputStream and ChannelInputStream, offload work to lower layers using
> NIO channels. This provides shorter execution time and reduced resource
> consumption. Unfortunately, this effect is prevented once the input strea
On Sun, 20 Nov 2022 07:45:11 GMT, Alan Bateman wrote:
>> Since JDK 18 some implementations of InputStream.transferTo, namely
>> FileInputStream and ChannelInputStream, offload work to lower layers using
>> NIO channels. This provides shorter execution time and reduced resource
>> consumption.
On Sun, 20 Nov 2022 09:07:21 GMT, Markus KARG wrote:
>> There is no need to use a temporary Vector within the constructor of
>> SynchronizedInputStream, as more efficient (non-synchronized) alternative
>> code (like List.of) will do the same in possibly less time. While the
>> optimization is
On Sun, 20 Nov 2022 02:16:02 GMT, Jaikiran Pai wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> allowing s2 to be null
>
> src/java.base/share/classes/java/io/SequenceInputStream.java line 83:
>
>> 81: */
>> 82
On Sun, 20 Nov 2022 07:56:59 GMT, Alan Bateman wrote:
> Jai is correct, this constructor appears to have tolerated null in the second
> parameter since JDK 1.0 so we need to proceed with care.
I have fixe this in
https://github.com/openjdk/jdk/pull/11249/commits/b6ccec209f3989ca37ac15585d27e28
> There is no need to use a temporary Vector within the constructor of
> SynchronizedInputStream, as more efficient (non-synchronized) alternative
> code (like List.of) will do the same in possibly less time. While the
> optimization is not dramatic, it still makes sense to replace Vector unless
On Sat, 19 Nov 2022 21:36:56 GMT, Markus KARG wrote:
> There is no need to use a temporary Vector within the constructor of
> SynchronizedInputStream, as more efficient (non-synchronized) alternative
> code (like List.of) will do the same in possibly less time. While the
> optimization is not
34 matches
Mail list logo
