On Mon, 20 May 2024 13:20:17 GMT, Oussama Louati wrote:
>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code
>> private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle,
>> MethodType, and CallSite constants.
>> It currently uses ad-hoc code to
On Wed, 28 Feb 2024 14:21:16 GMT, Glavo wrote:
>> Using `ByteArrayLittleEndian` is simpler and faster.
>>
>> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
>>
>>
>> Benchmark (size) Mode Cnt Score Erro
On Wed, 28 Feb 2024 07:17:42 GMT, Jaikiran Pai wrote:
> Hello Glavo, I'll need some more time on this to review this. In the
> meantime, could you update the micro benchmark latest numbers with this
> latest state?
Latest results:
Benchmark (size)
15 39052.832 ± 107.496 ns/op
> + ZipFileOpen.openCloseZipFile 512 avgt 15 36275.539 ± 663.193 ns/op
> - ZipFileOpen.openCloseZipFile1024 avgt 15 77106.494 ± 4159.300 ns/op
> + ZipFileOpen.openCloseZipFile1024 avgt 15 71955.013 ± 2296.050 ns/op
Glavo has updated the pull reque
On Tue, 16 Jan 2024 15:16:45 GMT, Jaikiran Pai wrote:
>> Glavo 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 six additi
On Tue, 16 Jan 2024 16:38:34 GMT, Glavo wrote:
>> Using `ByteArrayLittleEndian` is simpler and faster.
>>
>> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
>>
>>
>> Benchmark (size) Mode Cnt Score Erro
15 39052.832 ± 107.496 ns/op
> + ZipFileOpen.openCloseZipFile 512 avgt 15 36275.539 ± 663.193 ns/op
> - ZipFileOpen.openCloseZipFile1024 avgt 15 77106.494 ± 4159.300 ns/op
> + ZipFileOpen.openCloseZipFile1024 avgt 15 71955.013 ± 2296.050 ns/op
Glavo has updated the pull r
On Mon, 20 Nov 2023 16:24:31 GMT, Glavo wrote:
>> Using `ByteArrayLittleEndian` is simpler and faster.
>>
>> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
>>
>>
>> Benchmark (size) Mode Cnt Score Erro
On Mon, 15 Jan 2024 22:16:13 GMT, Glavo wrote:
> In the early development stage of JApp, I used 32-bit integers to store
> metadata such as resource size. But after using zstd to compress the
> metadata, I was surprised to find that storing them as 64-bit integers can
> act
On Mon, 15 Jan 2024 16:08:35 GMT, Claes Redestad wrote:
> I'd very much welcome support for zstd, both for resource content and
> metadata. A larger JEP-sized project, that.
>
> I have run a quick experiment with adding a more compact header format
> (16-bit sizes for the four fields) and on
On Fri, 12 Jan 2024 18:45:39 GMT, Glavo wrote:
> I generated runtime images using `jlink --compress 2 --add-modules
> java.se,jdk.unsupported,jdk.management` and then ran the following JMH
> benchmark:
>
>
> @Warmup(iterations = 10, time = 2)
> @Measurement(iterations =
the metadata. I tried
using zstd to compress the metadata in [JApp](https://github.com/Glavo/japp)
and got good results. We might be able to do this in jimage as well.
-
PR Comment: https://git.openjdk.org/jdk/pull/17405#issuecomment-1891175153
On Fri, 12 Jan 2024 18:45:39 GMT, Glavo wrote:
> I generated runtime images using `jlink --compress 2 --add-modules
> java.se,jdk.unsupported,jdk.management` and then ran the following JMH
> benchmark:
>
>
> @Warmup(iterations = 10, time = 2)
> @Measurement(iterations =
I generated runtime images using `jlink --compress 2 --add-modules
java.se,jdk.unsupported,jdk.management` and then ran the following JMH
benchmark:
@Warmup(iterations = 10, time = 2)
@Measurement(iterations = 5, time = 3)
@Fork(value = 1, jvmArgsAppend = {"-XX:+UseG1GC", "-Xms8g", "-Xmx8g",
On Wed, 8 Nov 2023 11:55:22 GMT, Glavo wrote:
> This PR significantly speeds up decompressing resources in Jimage while
> significantly reducing temporary memory allocations in the process.
>
> This will improve startup speed for runtime images generated using `jlink
&g
On Wed, 8 Nov 2023 11:55:22 GMT, Glavo wrote:
> This PR significantly speeds up decompressing resources in Jimage while
> significantly reducing temporary memory allocations in the process.
>
> This will improve startup speed for runtime images generated using `jlink
&g
ion, because compared to zip, it is not
superior in file size or decompression speed. However, I did some experiments
in the [JApp](https://github.com/Glavo/japp) project and found that the file
size using a mixture of string sharing + zstd compression was significantly
smaller than using only zstd,
On Fri, 8 Dec 2023 22:38:56 GMT, Claes Redestad wrote:
>> Does anyone want to take a look at this PR?
>
>> Does anyone want to take a look at this PR?
>
> RFE: https://bugs.openjdk.org/browse/JDK-8321620 - update the bug ID and this
> should PR should reach a wider audience. I'll have some
On Wed, 8 Nov 2023 11:55:22 GMT, Glavo wrote:
> This PR significantly speeds up decompressing resources in Jimage while
> significantly reducing temporary memory allocations in the process.
>
> This will improve startup speed for runtime images generated using `jlink
&g
anced
> users should definitively prefer the latter when working with system
> libraries (esp. when doing so using the FFM's Linker).
>
Well, it looks more difficult than I thought.
Maybe we could do something simpler, like just add those paths from the
multiarch specification to the d
is email to panama-dev as well.
I think this proposal is of great significance to Panama, as it will make
it easier for developers to develop wrappers for platform libraries.
Glavo
On Thu, Jan 4, 2024 at 3:12 PM David Holmes wrote:
> On 4/01/2024 1:36 pm, Glavo wrote:
> > He
then recursively read, parse and interpret more files.
>
Yes, this is exactly the behavior I want.
Glavo
On Tue, Jan 2, 2024 at 10:08 AM David Holmes
wrote:
> Hi Glavo,
>
> On 24/12/2023 4:18 am, Glavo wrote:
> > Hi,
> >
> > There are already many Linux distribution
I created a PR[1] to optimize the implementation of `nextBytes` in Random
and RandomGenerator by using Unsafe and ByteArrayLittleEndian.
JMH benchmarking says it's very useful, with performance improvements of up
to 180% in some cases.
Would anyone like to take a look at it?
Glavo
[1]: https
this suggestion?
Glavo
[1]: https://wiki.ubuntu.com/MultiarchSpec
On Mon, 20 Nov 2023 17:18:11 GMT, Per Minborg wrote:
> Can we use `Objects::checkIndex` here instead?
No, because these classes need to be compiled with `--release 8`.
Javadoc:
/**
* @implNote This class needs to maintain JDK 8 source compatibility.
*
* It is used internally in the JDK to
This PR significantly speeds up decompressing resources in Jimage while
significantly reducing temporary memory allocations in the process.
This will improve startup speed for runtime images generated using `jlink
--compress 1` and `jlink --compress 2` .
I generated a runtime image containing
On Wed, 8 Nov 2023 11:55:22 GMT, Glavo wrote:
> This PR significantly speeds up decompressing resources in Jimage while
> significantly reducing temporary memory allocations in the process.
>
> This will improve startup speed for runtime images generated using `jlink
&g
On Thu, 9 Nov 2023 02:07:57 GMT, Chen Liang wrote:
>> This PR significantly speeds up decompressing resources in Jimage while
>> significantly reducing temporary memory allocations in the process.
>>
>> This will improve startup speed for runtime images generated using `jlink
>> --compress 1`
On Mon, 20 Nov 2023 23:36:51 GMT, Claes Redestad wrote:
> But to make comparisons fair you need to take care to compare apples to
> apples: is the uncompressed baseline a similar jlink image generated without
> --compress? Or the default JDK image (uncompressed, with CDS)?
The uncompressed
(31.12% faster).
Can anyone review it? Thank you so much!
Glavo
[1]: https://github.com/openjdk/jdk/pull/16556
15 39052.832 ± 107.496 ns/op
> + ZipFileOpen.openCloseZipFile 512 avgt 15 36275.539 ± 663.193 ns/op
> - ZipFileOpen.openCloseZipFile1024 avgt 15 77106.494 ± 4159.300 ns/op
> + ZipFileOpen.openCloseZipFile1024 avgt 15 71955.013 ± 2296.050 ns/op
Glavo has updated the pull reque
al Latin-1 characters,
> `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so
> users can make the compiler happy without using useless try-catch statements.
Glavo has updated the pull request with a new target base due to a merge or a
rebase. The incremental webrev excludes th
On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen wrote:
>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to
>> use try...catch to handle CharacterCodingException and throw
>> IllegalArgumentException instead of CharacterCodingException to make the
>> calling code
al Latin-1 characters,
> `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so
> users can make the compiler happy without using useless try-catch statements.
Glavo has updated the pull request with a new target base due to a merge or a
rebase. The incremental webrev excludes th
15 39052.832 ± 107.496 ns/op
> + ZipFileOpen.openCloseZipFile 512 avgt 15 36275.539 ± 663.193 ns/op
> - ZipFileOpen.openCloseZipFile1024 avgt 15 77106.494 ± 4159.300 ns/op
> + ZipFileOpen.openCloseZipFile1024 avgt 15 71955.013 ± 2296.050 ns/op
Glavo has updated the pull reque
On Mon, 25 Sep 2023 09:47:15 GMT, Chen Liang wrote:
> UTF8 decoder does not perform any internal state mutation during decoding;
Are you sure? I think `CharsetDecoder::decode` will modify the `status` field.
-
PR Review Comment:
On Thu, 21 Sep 2023 16:40:59 GMT, Per Minborg wrote:
>> This PR outlines a solution for making immutable maps `@ValueBased` by
>> removing cacheing of certain values in `AbstractMap`.
>>
>> By removing these caching fields in `AbstractMap`, we can make the immutable
>> maps `@ValueBased` and
nsafe`, which reduces the impact on startup
> time.
Glavo 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 16 additional commits since the last
re
15 39052.832 ± 107.496 ns/op
> + ZipFileOpen.openCloseZipFile 512 avgt 15 36275.539 ± 663.193 ns/op
> - ZipFileOpen.openCloseZipFile1024 avgt 15 77106.494 ± 4159.300 ns/op
> + ZipFileOpen.openCloseZipFile1024 avgt 15 71955.013 ± 2296.050 ns/op
Glavo has updated the pull reque
On Mon, 3 Jul 2023 20:53:34 GMT, Glavo wrote:
> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.
This pull request has now been integrated.
Changeset: b32d6411
Author: Glavo
Committer: Naoto Sato
URL:
https://git.openjdk.org/jdk/com
On Tue, 15 Aug 2023 10:48:29 GMT, Glavo wrote:
>> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.
>
> Glavo has updated the pull request with a new target base due to a merge or a
> rebase. The pull request now contains four commits:
>
> - Merge r
On Tue, 15 Aug 2023 10:48:29 GMT, Glavo wrote:
>> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.
>
> Glavo has updated the pull request with a new target base due to a merge or a
> rebase. The pull request now contains four commits:
>
> - Merge r
> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.
Glavo has updated the pull request with a new target base due to a merge or a
rebase. The pull request now contains four commits:
- Merge remote-tracking branch 'origin/master' into case-conversion-java-base
- Rev
On Thu, 20 Jul 2023 16:47:14 GMT, Maurizio Cimadamore
wrote:
>> On a newer processor/OS (Alder Lake/Ubuntu 22.04) I see a bit more
>> difference:
>>
>>
>> Benchmark Mode Cnt Score Error Units
>> ByteArray.readBytethrpt5 680397.046 ±
On Thu, 20 Jul 2023 16:24:09 GMT, Maurizio Cimadamore
wrote:
> Here's with the same parameters as the one you are using:
I don't understand why there is such a difference. I have replicated similar
results on several other devices:
Apple M1:
Benchmark Mode Cnt
On Thu, 20 Jul 2023 16:01:27 GMT, Maurizio Cimadamore
wrote:
> I don't see 2x slowdown. Which JDK are you using? Which platform?
I tried running the benchmarks with OpenJDK 20.0.1 and my own jdk built from
master and the results were similar. The test platform is based on Ubuntu
23.04, and
On Thu, 20 Jul 2023 15:49:10 GMT, Maurizio Cimadamore
wrote:
>>> > it's likely to introduce non-trivial additional overhead
>>>
>>> What do you mean? E.g. where would the overhead come from?
>>
>> You suggested changes stored the ByteBuffer into a field. I measured
>> throughput with JMH,
On Thu, 20 Jul 2023 15:34:33 GMT, Maurizio Cimadamore
wrote:
> > it's likely to introduce non-trivial additional overhead
>
> What do you mean? E.g. where would the overhead come from?
You suggested changes stored the ByteBuffer into a field. I measured throughput
with JMH, and it shows that
On Thu, 20 Jul 2023 14:53:36 GMT, Glavo wrote:
>> @mcimadamore I compared the performance of `ByteBuffer` and `VarHandle`
>> using a JMH benchmark:
>>
>>
>> public class ByteArray {
>>
>> private byte[] array;
>> private ByteBu
On Thu, 20 Jul 2023 14:49:48 GMT, Glavo wrote:
>> Also, note that ByteBuffer exposes its backing array (at least if the buffer
>> is not read only) via ByteBuffer::array. This does no copy. So in all the
>> various stream implementations, I believe we can really just us
On Thu, 20 Jul 2023 14:15:15 GMT, Maurizio Cimadamore
wrote:
>>> Also... `Integer::toString` seems to be `@IntrinsicCandidate` ?
>>
>> It's just a bytecode intrinsics, it is only replaced when used in a
>> fluent-chain of StringBuilder/Buffer.
>
> Also, note that ByteBuffer exposes its
On Thu, 20 Jul 2023 13:46:10 GMT, Maurizio Cimadamore
wrote:
> Also... `Integer::toString` seems to be `@IntrinsicCandidate` ?
It's just a bytecode intrinsics, it is only replaced when used in a
fluent-chain of StringBuilder/Buffer.
-
PR Review Comment:
`Objects.equals` help with
>>> JIT? If it helps, then I think adding `@ForceInline` might be a better
>>> solution.
>>
>> I added `@ForceInline` on `Objects.hashCode(Object)`, but the JMH results
>> did not change.
>
> @Glavo I have created a test case wi
On Thu, 20 Jul 2023 01:11:43 GMT, Glavo wrote:
> The changes to `Arrays.hashCode(Object[])` in JDK-8312164 caused its
> performance is reduced by about 80%.
>
> This PR reverts this change.
JMH Benchmark:
public class HashCode {
@Param({"1", "10", "
The changes to `Arrays.hashCode(Object[])` in JDK-8312164 caused its
performance is reduced by about 80%.
This PR reverts this change.
-
Commit messages:
- Add benchmark
- Revert changes to Arrays.hashCode(Object[]) in JDK-8312164
Changes:
On Wed, 19 Jul 2023 13:14:23 GMT, Pavel Rappo wrote:
>> Please review this PR to refactor Arrays.hashCode for long[], boolean[], and
>> Object[]. I've been told elsewhere that it shouldn't have significant
>> performance implications.
>
> Pavel Rappo has updated the pull request incrementally
On Fri, 14 Jul 2023 13:01:46 GMT, Glavo wrote:
>>> However, while I think this corrects the behavior, this caused a change in
>>> the behavior of the API, so a CSR may be required. I don't want to debate
>>> this in this PR, so I'll revert this change and
On Fri, 14 Jul 2023 10:24:47 GMT, Alan Bateman wrote:
> It might be that the conclusion is that it's just too risky to change, in
> which case Uwe's suggestion is good and would avoid it showing up on
> someone's else radar in the future.
Until we're sure we want to normalize a usage of
nsafe`, which reduces the impact on startup
> time.
Glavo 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 15 additional commits since the last
re
On Thu, 13 Jul 2023 09:27:03 GMT, Pavel Rappo wrote:
> > @pavelrappo Actually I look at the implementation of
> > `ArraySupport.vectorizedHashCode` and it does branching and only uses
> > vector instructions if the length is sufficiently large. Please do
> > benchmarking if you are uncertain
On Wed, 12 Jul 2023 16:05:03 GMT, Uwe Schindler wrote:
> Maybe a small suggestion to make it clear whats wanted here. In other
> projects I am involved in (Apache Lucene/Solr, Apache TIKA, PostgresSQL JDBC,
> Checkstyle itsself, Elasticserach/Opensearch), which use the [forbiddenapis
>
> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.
Glavo has updated the pull request incrementally with one additional commit
since the last revision:
Revert StreamTokenizer.java
-
Changes:
- all: https://git.openjdk.org/jdk/pull/14763/files
- new: ht
On Wed, 12 Jul 2023 13:26:03 GMT, Alan Bateman wrote:
> I suspect this change to StreamTokenizer needs eyes. I think long standing
> behavior of the lowerCaseMode(true) has been to use the rules for the default
> locale so we need to be careful.
I investigated some usage of this method on
Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.
-
Commit messages:
- Update DateTimeFormatterBuilder
- Avoid locale-sensitive case conversions in java.base
Changes: https://git.openjdk.org/jdk/pull/14763/files
Webrev:
On Tue, 27 Jun 2023 20:29:36 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
&
On Fri, 7 Jul 2023 15:56:13 GMT, Brian Burkhalter wrote:
>> Add a default method `java.io.Closeable::closeUnchecked` which is equivalent
>> to `Closeable::close` except that it instead throws
>> `java.io.UncheckedIOException`.
>
> Brian Burkhalter has updated the pull request incrementally
On Fri, 7 Jul 2023 15:56:13 GMT, Brian Burkhalter wrote:
>> Add a default method `java.io.Closeable::closeUnchecked` which is equivalent
>> to `Closeable::close` except that it instead throws
>> `java.io.UncheckedIOException`.
>
> Brian Burkhalter has updated the pull request incrementally
al Latin-1 characters,
> `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so
> users can make the compiler happy without using useless try-catch statements.
Glavo has updated the pull request incrementally with one additional commit
since the last revision:
Use ne
al Latin-1 characters,
> `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so
> users can make the compiler happy without using useless try-catch statements.
Glavo has updated the pull request with a new target base due to a merge or a
rebase. The incremental webrev excludes th
On Mon, 3 Jul 2023 09:21:54 GMT, 温绍锦 wrote:
> another example:
>
> ```
> String str0 = new String(new byte[]{-1}, StandardCharsets.ISO_8859_1);
> String str1 = str0.toUpperCase();
> ```
>
> str0.coder is LATIN1 str1.coder is UTF16
I know this, these cases only happen with `toUpperCase`, not
On Mon, 3 Jul 2023 09:17:29 GMT, 温绍锦 wrote:
>> src/java.base/share/classes/java/lang/StringLatin1.java line 442:
>>
>>> 440: if (!canEncode(cp)) { // not a latin1
>>> character
>>> 441: return toLowerCaseEx(str, value, first, locale, false);
>>>
On Mon, 3 Jul 2023 04:02:44 GMT, 温绍锦 wrote:
> # Benchmark Result
>
>
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.lang.StringUpperLower.*"
>
>
>
> ## 1.
>
On Wed, 28 Jun 2023 22:19:04 GMT, 温绍锦 wrote:
>> Speed up Integer.toString with a precomputed cache array of length 1000, use
>> division by 1000, so that each iteration can calculate three digits.
>>
>> this optimization can also be used in StringBuilder#appent(int) and
>> Long#toString.
>>
On Wed, 28 Jun 2023 22:19:04 GMT, 温绍锦 wrote:
>> Speed up Integer.toString with a precomputed cache array of length 1000, use
>> division by 1000, so that each iteration can calculate three digits.
>>
>> this optimization can also be used in StringBuilder#appent(int) and
>> Long#toString.
>>
On Thu, 29 Jun 2023 07:41:29 GMT, Alan Bateman wrote:
> You'll need to go back through the discussion in the original PRs (there was
> more than one) as there was lengthy discussion this already.
https://github.com/openjdk/jdk/pull/11840#discussion_r1064489163
Are you referring to this
On Sun, 29 Jan 2023 15:37:28 GMT, Glavo wrote:
> When the default Locale is `tr`, the jmod and jimage commands have the
> following problems:
>
> * The jmod command does not correctly recognize the `list` mode typed in
> lowercase;
> * The jimage command cannot obtain th
On Tue, 27 Jun 2023 20:29:36 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
&
On Wed, 28 Jun 2023 17:06:56 GMT, 温绍锦 wrote:
> Speed up Integer.toString with a precomputed cache array of length 1000, use
> division by 1000, so that each iteration can calculate three digits.
>
> this optimization can also be used in StringBuilder#appent(int) and
> Long#toString.
>
> #
On Wed, 28 Jun 2023 01:45:51 GMT, Chen Liang wrote:
> On a side note, `NoRepl` means "no replication", implying the passed array is
> already trusted. I think you should do something like this instead:
I think `NoRepl` means "no replace", it's an ambiguous acronym.
It cannot be replaced by
nsafe`, which reduces the impact on startup
> time.
Glavo has updated the pull request incrementally with one additional commit
since the last revision:
add 8310843 to @bug
-
Changes:
- all: https://git.openjdk.org/jdk/pull/14636/files
- new: https://git.openjdk.org/jdk/p
On Tue, 27 Jun 2023 17:58:05 GMT, Roger Riggs wrote:
> It takes a local inconvenience try/catch and spreads the impact over multiple
> files and packages as well as bulking up JLA.
I don't quite understand what you mean.
The main goal of this PR is to get rid of those annoying try-catch, but
On Tue, 27 Jun 2023 11:25:32 GMT, 温绍锦 wrote:
>> 温绍锦 has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1
>
>> I'm looking through
>>
On Tue, 27 Jun 2023 07:45:51 GMT, Glavo wrote:
>> When the default Locale is `tr`, the jmod and jimage commands have the
>> following problems:
>>
>> * The jmod command does not correctly recognize the `list` mode typed in
>> lowercase;
>> * The j
> When the default Locale is `tr`, the jmod and jimage commands have the
> following problems:
>
> * The jmod command does not correctly recognize the `list` mode typed in
> lowercase;
> * The jimage command cannot obtain the help information of the `list` mode.
Glavo ha
On Tue, 27 Jun 2023 14:23:53 GMT, Chen Liang wrote:
>>> What I suggest is to prepare the array only once (in the static block as it
>>> is now), but have each class that use it encapsulate is own copy - obtained
>>> from clone(). Surely 256 shorts is not so large that we can't have two
>>>
On Tue, 27 Jun 2023 14:02:52 GMT, Daniel Fuchs wrote:
> What I suggest is to prepare the array only once (in the static block as it
> is now), but have each class that use it encapsulate is own copy - obtained
> from clone(). Surely 256 shorts is not so large that we can't have two arrays?
On Tue, 27 Jun 2023 13:10:40 GMT, Daniel Fuchs wrote:
> It's a bit smelly to have a public static field of type array. Static
> analysers are likely to flag this. It would be better to make the field
> private and have a public static method that returns DIGITS.clone() - then
> each class
On Tue, 27 Jun 2023 11:27:18 GMT, 温绍锦 wrote:
> do I need to change the copyright information? I am not sure
Yes, you should update the copyright information of each file you have modified.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243607127
On Wed, 7 Jun 2023 06:32:31 GMT, Jaikiran Pai wrote:
> Sounds fine to me and as other have agreed `Locale.ROOT` would be more
> appropriate. Would you be willing to update this PR to update the few other
> occurences in some classes (`JImageTask`, `JlinkTask` and
> `VersionPropsPlugin`) as
15 39052.832 ± 107.496 ns/op
> + ZipFileOpen.openCloseZipFile 512 avgt 15 36275.539 ± 663.193 ns/op
> - ZipFileOpen.openCloseZipFile1024 avgt 15 77106.494 ± 4159.300 ns/op
> + ZipFileOpen.openCloseZipFile1024 avgt 15 71955.013 ± 2296.050 ns/op
Glavo has updated the pull reque
> When the default Locale is `tr`, the jmod and jimage commands have the
> following problems:
>
> * The jmod command does not correctly recognize the `list` mode typed in
> lowercase;
> * The jimage command cannot obtain the help information of the `list` mode.
Glavo ha
al Latin-1 characters,
> `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so
> users can make the compiler happy without using useless try-catch statements.
Glavo has updated the pull request with a new target base due to a merge or a
rebase. The incremental webrev excludes th
nsafe`, which reduces the impact on startup
> time.
Glavo 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 13 additional commits since the last
re
> When the default Locale is `tr`, the jmod and jimage commands have the
> following problems:
>
> * The jmod command does not correctly recognize the `list` mode typed in
> lowercase;
> * The jimage command cannot obtain the help information of the `list` mode.
Glavo ha
al Latin-1 characters,
> `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so
> users can make the compiler happy without using useless try-catch statements.
Glavo has updated the pull request with a new target base due to a merge or a
rebase. The incremental webrev excludes th
15 39052.832 ± 107.496 ns/op
> + ZipFileOpen.openCloseZipFile 512 avgt 15 36275.539 ± 663.193 ns/op
> - ZipFileOpen.openCloseZipFile1024 avgt 15 77106.494 ± 4159.300 ns/op
> + ZipFileOpen.openCloseZipFile1024 avgt 15 71955.013 ± 2296.050 ns/op
Glavo has updated the pull reque
nsafe`, which reduces the impact on startup
> time.
Glavo 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 12 additional commits since the last
re
On Mon, 26 Jun 2023 16:02:57 GMT, Chen Liang wrote:
> This is just a copycat of the original newStringNoRepl, which should be
> fixed; newStringUTF8NoRepl has no such issue.
Unfortunately, the behavior of `newStringUTF8NoRepl` is not the same as that of
`newStringNoRepl`, as it actually
al Latin-1 characters,
> `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so
> users can make the compiler happy without using useless try-catch statements.
Glavo has updated the pull request incrementally with one additional commit
since the last revision:
update javadoc
Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
Reasons:
* Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating
a new shortcut can make writing shorter;
* Since all possible values of `byte` are legal Latin-1 characters,
`newStringLatin1NoRepl`
1 - 100 of 217 matches
Mail list logo
