8329251: Print custom truststore/ keystore name
-
Commit messages:
- JDK-8329251
Changes: https://git.openjdk.org/jdk/pull/20414/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20414&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8329251
Stats: 167 lines in 5 files
On Sat, 27 Jul 2024 15:00:51 GMT, Archie Cobbs wrote:
>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data
>> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In
>> order to do this, after a GZIP trailer frame is read, it attempts to read a
>
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Wed, 31 Jul 2024 21:54:15 GMT, fitzsim wrote:
>> 8334048: -Xbootclasspath can not read some ZIP64 zip files
>
> fitzsim has updated the pull request incrementally with one additional commit
> since the last revision:
>
> BootClassPathZipFileTest: Switch to createClassBytes, createZip stati
> 8334048: -Xbootclasspath can not read some ZIP64 zip files
fitzsim has updated the pull request incrementally with one additional commit
since the last revision:
BootClassPathZipFileTest: Switch to createClassBytes, createZip static
functions
-
Changes:
- all: https://git.op
> 8334048: -Xbootclasspath can not read some ZIP64 zip files
fitzsim has updated the pull request incrementally with six additional commits
since the last revision:
- BootClassPathZipFileTest: Add test
- BootClassPathZip64Test: Remove test
- BootClassPathZip64Test: Delete class file in finall
On Wed, 12 Jun 2024 14:02:58 GMT, fitzsim wrote:
> 8334048: -Xbootclasspath can not read some ZIP64 zip files
It turns out ZIP64 is underrepresented in the test suite in general; for
example, https://bugs.openjdk.org/browse/JDK-8185896 is still open.
Using the Java class library alone, I have
On Wed, 31 Jul 2024 18:52:12 GMT, fabioromano1 wrote:
>> I have implemented the Zimmermann's square root algorithm, available in
>> works [here](https://inria.hal.science/inria-00072854/en/) and
>> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>>
>> The
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the New
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the New
Hi Anthony,
>The use case is a time series, which has methods to return a Stream of data
>points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are
>several Gatherer factory methods, one of which is `GathererDataPoint> withInterpolationAt(NavigableSet instants)`. If
>`instants.is
On Wed, 31 Jul 2024 13:40:31 GMT, Jorn Vernee wrote:
> This test spawns 2 forked processes, which then try to trigger a code cache
> OOM in FFM hotspot code. Even without `-Xcomp`, the test is already pretty
> slow, which increases dramatically with `-Xcomp`, since startup Java code has
> to b
On Sat, 27 Jul 2024 15:01:30 GMT, fabioromano1 wrote:
>> On my M1 Pro/32 GiB
>>
>> Current
>>
>> Benchmark Mode CntScore
>> Error Units
>> BigIntegerSquareRoot.testBigSqrtAndRemainderavgt 15 45.655 ?
>> 0.273 ns/op
>> BigInt
On Tue, 30 Jul 2024 19:00:13 GMT, Archie Cobbs wrote:
> Another (more conservative) possibility is to preserve both 1 ("Trailing
> garbage is ignored") and 3 ("Concatenated streams are automatically decoded")
> in the default configuration.
>
> Then basically all we would be changing is no lon
On Wed, 31 Jul 2024 13:40:31 GMT, Jorn Vernee wrote:
> This test spawns 2 forked processes, which then try to trigger a code cache
> OOM in FFM hotspot code. Even without `-Xcomp`, the test is already pretty
> slow, which increases dramatically with `-Xcomp`, since startup Java code has
> to b
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Wed, 31 Jul 2024 13:40:31 GMT, Jorn Vernee wrote:
> This test spawns 2 forked processes, which then try to trigger a code cache
> OOM in FFM hotspot code. Even without `-Xcomp`, the test is already pretty
> slow, which increases dramatically with `-Xcomp`, since startup Java code has
> to b
This test spawns 2 forked processes, which then try to trigger a code cache OOM
in FFM hotspot code. Even without `-Xcomp`, the test is already pretty slow,
which increases dramatically with `-Xcomp`, since startup Java code has to be
compiled 3 times, once for the main test process, and then 2
On Sun, 28 Jul 2024 15:59:05 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
19 matches
Mail list logo
