Re: Will it be worthy to add some public static final empty arrays for some most used types in some place in java.base, other than create them multi times in several places?

[Xeno Amess]

sample codes here https://github.com/openjdk/jdk/pull/5874 if anyone
interested


Xeno Amess  于2021年10月10日周日 上午4:00写道：

> sigh.
>
> quite some good things I always want are at valhalla
> , but I just don't think
> they will come stable soon.
>
> hope me be wrong.
>
>
> Pavel Rappo  于2021年10月10日周日 上午1:54写道：
>
>> Empty? As in arrays of length zero?
>>
>> There ought to be a much better solution. I'm neither an expert nor
>> (sadly) an active follower of the Valhalla project [1]. Perhaps something
>> there or in Frozen Arrays [2] will address the runtime cost of creating
>> zero-length arrays much more elegantly.
>>
>> [1] https://openjdk.java.net/projects/valhalla/
>> [2] https://openjdk.java.net/jeps/8261007
>>
>> -Pavel
>>
>> > On 9 Oct 2021, at 18:19, Xeno Amess  wrote:
>> >
>> > I suggest putting them in Arrays btw.
>>
>>

Re: Will it be worthy to add some public static final empty arrays for some most used types in some place in java.base, other than create them multi times in several places?

[Xeno Amess]

sigh.

quite some good things I always want are at valhalla
, but I just don't think they
will come stable soon.

hope me be wrong.


Pavel Rappo  于2021年10月10日周日 上午1:54写道：

> Empty? As in arrays of length zero?
>
> There ought to be a much better solution. I'm neither an expert nor
> (sadly) an active follower of the Valhalla project [1]. Perhaps something
> there or in Frozen Arrays [2] will address the runtime cost of creating
> zero-length arrays much more elegantly.
>
> [1] https://openjdk.java.net/projects/valhalla/
> [2] https://openjdk.java.net/jeps/8261007
>
> -Pavel
>
> > On 9 Oct 2021, at 18:19, Xeno Amess  wrote:
> >
> > I suggest putting them in Arrays btw.
>
>

RFR: 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE

[Andrey Turbanov]

8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE

-

Commit messages:
 - [PATCH] Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE

Changes: https://git.openjdk.java.net/jdk/pull/5878/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5878=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275002
  Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5878.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5878/head:pull/5878

PR: https://git.openjdk.java.net/jdk/pull/5878

Re: Unexepcted OutOfMemoryError from Arrays.deepToString

[Andrey Turbanov]

Created PR to remove AbstractStringBuilder.MAX_ARRAY_SIZE -
https://github.com/openjdk/jdk/pull/5878

BTW, I found one more place where Integer.MAX_VALUE is used as maximum
array length - 
java.util.concurrent.ScheduledThreadPoolExecutor.DelayedWorkQueue#grow
I think this method could be reworked to take advantage of
ArraysSupport.newLength method too.


Andrey Turbanov

сб, 9 окт. 2021 г. в 20:09, Pavel Rappo :
>
>
>
> > On 9 Oct 2021, at 13:07, Pavel Rappo  wrote:
> >
> > 
> >
> > Separately, java.lang.AbstractStringBuilder#MAX_ARRAY_SIZE seems unused; I 
> > wonder how that happened.
>
> I found what happened:
>
> $ git log -S "MAX_ARRAY_SIZE" -- 
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java
> commit 03642a01af7123298d6524a98c99a3934d35c11b
> Author: Jim Laskey 
> Date:   Thu Jun 11 10:08:23 2020 -0300
>
> 8230744: Several classes throw OutOfMemoryError without message
>
> Reviewed-by: psandoz, martin, bchristi, rriggs, smarks
>
> Looking at the corresponding review thread, 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/066874.html, 
> the question about "the local orphan" MAX_ARRAY_SIZE was raised by Martin and 
> subsequently addressed by Jim. The problem is, there were two of these 
> fields. The one in PriorityBlockingQueue was spotted and deleted, the one in 
> AbstractStringBuilder was not.
>
> Andrey, regardless of the outcome of your main question (OOM from 
> Arrays.deepToString), would be willing to publish a PR to delete that field 
> in AbstractStringBuilder?
>
> -Pavel
>
> >
> > -Pavel
> >
> >> On 9 Oct 2021, at 11:38, Andrey Turbanov  wrote:
> >>
> >> Hello.
> >> I came across unexpected behaviour of Arrays.deepToString method.
> >> It throws OOM even on non-huge arrays.
> >> For example this code:
> >>
> >>   int size = Integer.MAX_VALUE / 19;
> >>   Integer[] integers = new Integer[size];
> >>   Arrays.fill(integers, 0);
> >>  System.out.println(Arrays.deepToString(integers));
> >>
> >> Fails with following stack trace:
> >>
> >> Exception in thread "main" java.lang.OutOfMemoryError: Requested array
> >> size exceeds VM limit
> >>   at 
> >> java.base/java.lang.AbstractStringBuilder.(AbstractStringBuilder.java:86)
> >>   at java.base/java.lang.StringBuilder.(StringBuilder.java:112)
> >>   at java.base/java.util.Arrays.deepToString(Arrays.java:5160)
> >>
> >>
> >> I believe it should be able to handle such arrays and not throw OOM
> >>
> >>
> >> Andrey Turbanov
> >
>

SourceVersion::feature

[Michael Bien]

Hello,

could javax.lang.model.SourceVersion receive a feature() method 
returning the version as an int, analog to java.lang.Runtime.Version?


if (SourceVersion.latest().feature() >= 18) {}

is simpler than comparing enums which may or may not exist dependent on 
the deployed java version and cleaner than ordinal() tricks.


best regards,

michael

Re: Will it be worthy to add some public static final empty arrays for some most used types in some place in java.base, other than create them multi times in several places?

[Pavel Rappo]

Empty? As in arrays of length zero?

There ought to be a much better solution. I'm neither an expert nor (sadly) an 
active follower of the Valhalla project [1]. Perhaps something there or in 
Frozen Arrays [2] will address the runtime cost of creating zero-length arrays 
much more elegantly.

[1] https://openjdk.java.net/projects/valhalla/
[2] https://openjdk.java.net/jeps/8261007

-Pavel

> On 9 Oct 2021, at 18:19, Xeno Amess  wrote:
> 
> I suggest putting them in Arrays btw.

Will it be worthy to add some public static final empty arrays for some most used types in some place in java.base, other than create them multi times in several places?

[Xeno Amess]

I suggest putting them in Arrays btw.

Re: Unexepcted OutOfMemoryError from Arrays.deepToString

[Pavel Rappo]

> On 9 Oct 2021, at 13:07, Pavel Rappo  wrote:
> 
> 
> 
> Separately, java.lang.AbstractStringBuilder#MAX_ARRAY_SIZE seems unused; I 
> wonder how that happened.

I found what happened:

$ git log -S "MAX_ARRAY_SIZE" -- 
src/java.base/share/classes/java/lang/AbstractStringBuilder.java
commit 03642a01af7123298d6524a98c99a3934d35c11b
Author: Jim Laskey 
Date:   Thu Jun 11 10:08:23 2020 -0300

8230744: Several classes throw OutOfMemoryError without message

Reviewed-by: psandoz, martin, bchristi, rriggs, smarks

Looking at the corresponding review thread, 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/066874.html, 
the question about "the local orphan" MAX_ARRAY_SIZE was raised by Martin and 
subsequently addressed by Jim. The problem is, there were two of these fields. 
The one in PriorityBlockingQueue was spotted and deleted, the one in 
AbstractStringBuilder was not.

Andrey, regardless of the outcome of your main question (OOM from 
Arrays.deepToString), would be willing to publish a PR to delete that field in 
AbstractStringBuilder?

-Pavel

> 
> -Pavel
> 
>> On 9 Oct 2021, at 11:38, Andrey Turbanov  wrote:
>> 
>> Hello.
>> I came across unexpected behaviour of Arrays.deepToString method.
>> It throws OOM even on non-huge arrays.
>> For example this code:
>> 
>>   int size = Integer.MAX_VALUE / 19;
>>   Integer[] integers = new Integer[size];
>>   Arrays.fill(integers, 0);
>>  System.out.println(Arrays.deepToString(integers));
>> 
>> Fails with following stack trace:
>> 
>> Exception in thread "main" java.lang.OutOfMemoryError: Requested array
>> size exceeds VM limit
>>   at 
>> java.base/java.lang.AbstractStringBuilder.(AbstractStringBuilder.java:86)
>>   at java.base/java.lang.StringBuilder.(StringBuilder.java:112)
>>   at java.base/java.util.Arrays.deepToString(Arrays.java:5160)
>> 
>> 
>> I believe it should be able to handle such arrays and not throw OOM
>> 
>> 
>> Andrey Turbanov
> 

Re: Unexepcted OutOfMemoryError from Arrays.deepToString

[Pavel Rappo]

This error has two causes. The first cause is that the VM cannot allocate 
arrays whose length exceeds Integer.MAX_VALUE - 8 (MAX_ARRAY_SIZE). The second 
cause is that Arrays.deepToString tries to pre-allocate 20 chars per string 
representation for each array element and maxes out at Integer.MAX_VALUE, which 
is above MAX_ARRAY_SIZE. One solution would be to change Arrays.deepToString to 
max out at MAX_ARRAY_SIZE.

Separately, java.lang.AbstractStringBuilder#MAX_ARRAY_SIZE seems unused; I 
wonder how that happened.

-Pavel

> On 9 Oct 2021, at 11:38, Andrey Turbanov  wrote:
> 
> Hello.
> I came across unexpected behaviour of Arrays.deepToString method.
> It throws OOM even on non-huge arrays.
> For example this code:
> 
>int size = Integer.MAX_VALUE / 19;
>Integer[] integers = new Integer[size];
>Arrays.fill(integers, 0);
>   System.out.println(Arrays.deepToString(integers));
> 
> Fails with following stack trace:
> 
> Exception in thread "main" java.lang.OutOfMemoryError: Requested array
> size exceeds VM limit
>at 
> java.base/java.lang.AbstractStringBuilder.(AbstractStringBuilder.java:86)
>at java.base/java.lang.StringBuilder.(StringBuilder.java:112)
>at java.base/java.util.Arrays.deepToString(Arrays.java:5160)
> 
> 
> I believe it should be able to handle such arrays and not throw OOM
> 
> 
> Andrey Turbanov

Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v2]

[Raffaello Giulietti]

On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti 
 wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 
>> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was 
>> a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about 
>> multi-line (block) comments. Nothing in the code proper has changed, except 
>> for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   4511638: Double.toString(double) sometimes produces incorrect results

(comment by Guy Steele)

Hi, Raffaello,

I will try to compose this message in plain ASCII and hope it does not get 
garbled.

I have now re-read the Schubfach paper, and with the extra information in your 
previous email, I think I understood it a lot better this time. I am very 
enthusiastic about the approach. This is exactly what JonL White was trying to 
puzzle out some five decades ago: just how many digits do you need in your 
powers of ten to get accurate print-read round-trips?

I am especially appreciative of the attention paid in the Schubfach paper to 
parameter M, which ensures that two-digit possibilities are considered in cases 
where it is required to print two significant digits anyway (scientific 
notation).

I have also read the two papers I could find about Ryu. Schubfach is clearly an 
improvement over Ryu because it avoids the iteration, among other reasons. But 
the second paper, about Ryu for printf, addresses the specific difficulties of 
generating digits for printf format specifiers, and raises the interesting 
question of whether it would be worthwhile also to design a version of 
Schubfach that handles printf requirements.

So I think it would be well worth incorporating the Schubfach algorithm into 
the JDK codebase. I am reassured that Schubfach has undergone extensive testing 
on trillions of randomly chosen values. But I would be further reassured by a 
statement that two important classes of values have been _exhaustively_ tested:

(1) All positive powers of 2 representable in the double format, plus the 
maximum representable value. (These are the values that are surrounded by 
irregular spacing.) Furthermore, out of caution one should also test every fp 
value within Z ulps of such a value; perhaps Z should be 64 or even 1024.

(2) All representable fp values that are the result of rounding-to-nearest some 
decimal value of the form y•10^n, where y is a member of, say, either D_1, D_2, 
D_3, or D_4. (These are values that may be especially susceptible to generation 
of too many digits by an insufficiently careful algorithm, and one reason might 
be insufficient precision or other algorithmic error in connection with a table 
of powers of ten.) Furthermore, out of caution one should also test every fp 
value within Y ulps of such a value; perhaps Y should be 64 or even 1024.

In every case, the testing should include (a) ensuring round-trip print-read 
behavior; (b) comparing to what is produced by the current JDK algorithm, and 
investigating any cases that differ.

And if other similar “edge cases” can be identified from the structure of the 
code, those would be worth focusing on as well.

If this testing has been or could be done, I would say, yes, certainly adopt 
Schubfach for Java. I would also recommend submitting the Schubfach paper to an 
appropriate conference or journal to get the benefit of further peer review of 
the algorithm and its write-up.

—Guy



(my reply)

Hi Guy,

for some reason your comments still appear garbled on the GitHub PR page and 
don't make it to the core-libs-dev mailing list at all. Luckily, they appear 
intelligible in my mailbox, so I'll keep going with prepending your comments in 
my replies: not ideal but good enough.

Thanks so much for re-reading my "paper".


printf()

There are some issues to consider when trying to apply Schubfach to printf(), 
the main one being that printf() allows to specify an arbitrary length for the 
resulting decimal. This means, for example, that unlimited precision arithmetic 
is unavoidable. But it might be worthwhile to investigate using Schubfach for 
lengths up to H (9 and 17 for float and double, resp.) and fall back to 
unlimited precision beyond that.
Before that, however, I would prefer to finally push Schubfach in the OpenJDK 
codebase for the toString() cases and close this PR.


Tests

Below, by "extensive test" I mean not only that the outcomes convert back 
without loss of information, but that they fully meet the spec about minimal 
number of digits, closeness, correct formatting (normal viz scientific), 
character set, etc.

All currently available tests are in the contributed code of this PR and will 
be part of the OpenJDK once integrated.

- All powers of 2 and the extreme values are already 

Unexepcted OutOfMemoryError from Arrays.deepToString

[Andrey Turbanov]

Hello.
I came across unexpected behaviour of Arrays.deepToString method.
It throws OOM even on non-huge arrays.
For example this code:

int size = Integer.MAX_VALUE / 19;
Integer[] integers = new Integer[size];
Arrays.fill(integers, 0);
   System.out.println(Arrays.deepToString(integers));

Fails with following stack trace:

Exception in thread "main" java.lang.OutOfMemoryError: Requested array
size exceeds VM limit
at 
java.base/java.lang.AbstractStringBuilder.(AbstractStringBuilder.java:86)
at java.base/java.lang.StringBuilder.(StringBuilder.java:112)
at java.base/java.util.Arrays.deepToString(Arrays.java:5160)


I believe it should be able to handle such arrays and not throw OOM


Andrey Turbanov

Re: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources

[Remi Forax]

- Original Message -
> From: "Tagir F.Valeev" 
> To: "core-libs-dev" 
> Sent: Lundi 4 Octobre 2021 08:51:55
> Subject: RFR: 8274412: Add a method to Stream API to consume and close the 
> stream without using try-with-resources

> Currently, when the stream holds a resource, it's necessary to wrap it with
> try-with-resources. This undermines the compact and fluent style of stream API
> calls. For example, if we want to get the `List` of files inside the directory
> and timely close the underlying filehandle, we should use something like this:
> 
> 
> List paths;
> try (Stream stream = Files.list(Path.of("/etc"))) {
>paths = stream.toList();
> }
> // use paths
> 
> 
> I suggest to add a new default method to Stream interface named
> `consumeAndClose`, which allows performing terminal stream operation and
> closing the stream at the same time. It may look like this:
> 
> 
>default  R consumeAndClose(Function, ? extends R> 
> function)
>{
>Objects.requireNonNull(function);
>try(this) {
>return function.apply(this);
>}
>}
> 
> 
> Now, it will be possible to get the list of the files in the fluent manner:
> 
> 
> List list = Files.list(Path.of("/etc")).applyAndClose(Stream::toList);


I would prefer the method to be called applyAndClose() because it is what the 
method does, it applies the function and closes the stream.

There are two missing information in the javadoc
- the function taken as parameter should not return a stream, because the 
stream will be closed
  This is not okay
List list = Files.list(Path.of("/etc")).applyAndClose(s -> 
s).toList();


- if there are intermediary operations, they have to be done in the function 
taken as parameter and not before calling applyAndClose()
  This is okay
List list = Files.list(Path.of("/etc")).applyAndClose(s -> 
s.map(path -> Integer.parseInt(path.toString())).toList());

  This is not okay
List list = Files.list(Path.of("/etc")).map(path -> 
Integer.parseInt(path.toString())).applyAndClose(Stream::toList);


In both case, IDEs can help, but i think it should be written explicitly in the 
javadoc.


> 
> -
> 
> Commit messages:
> - Fix tests
> - 8274412: Add a method to Stream API to consume and close the stream without
> using try-with-resources
> 
> Changes: https://git.openjdk.java.net/jdk/pull/5796/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5796=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8274412
>  Stats: 140 lines in 5 files changed: 135 ins; 0 del; 5 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/5796.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5796/head:pull/5796
> 
> PR: https://git.openjdk.java.net/jdk/pull/5796

Re: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources

[Tagir F . Valeev]

On Sun, 3 Oct 2021 11:00:25 GMT, Tagir F. Valeev  wrote:

> Currently, when the stream holds a resource, it's necessary to wrap it with 
> try-with-resources. This undermines the compact and fluent style of stream 
> API calls. For example, if we want to get the `List` of files inside the 
> directory and timely close the underlying filehandle, we should use something 
> like this:
> 
> 
> List paths;
> try (Stream stream = Files.list(Path.of("/etc"))) {
> paths = stream.toList();
> }
> // use paths
> 
> 
> I suggest to add a new default method to Stream interface named 
> `consumeAndClose`, which allows performing terminal stream operation and 
> closing the stream at the same time. It may look like this:
> 
> 
> default  R consumeAndClose(Function, ? extends R> 
> function) {
> Objects.requireNonNull(function);
> try(this) {
> return function.apply(this);
> }
> }
> 
> 
> Now, it will be possible to get the list of the files in the fluent manner:
> 
> 
> List list = Files.list(Path.of("/etc")).consumeAndClose(Stream::toList);

CSR is [posted](https://bugs.openjdk.java.net/browse/JDK-8274994), please 
review!

-

PR: https://git.openjdk.java.net/jdk/pull/5796

Re: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux

[Wu Yan]

On Wed, 1 Sep 2021 13:39:46 GMT, Naoto Sato  wrote:

>> Hi,
>> Please help me review the change to enhance getting  time zone ID from 
>> /etc/localtime on linux.
>> 
>> We use `realpath` instead of `readlink` to obtain the link name of 
>> /etc/localtime, because `readlink` can only read the value of a symbolic of 
>> link, not the canonicalized absolute pathname.
>> 
>> For example, the value of /etc/localtime is 
>> "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by 
>> `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of 
>> `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which 
>> consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you 
>> can get “/usr/share/zoneinfo/Asia/Shanghai“ directly from “/etc/localtime“.
>> 
>> Thanks,
>> wuyan
>
> The change looks reasonable. Please test your fix with macOS as well.

Hi, @naotoj, Could you do me a favor to review the patch?

-

PR: https://git.openjdk.java.net/jdk/pull/5327

Integrated: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo

[Wang Huang]

On Thu, 8 Jul 2021 11:50:36 GMT, Wang Huang  wrote:

> Dear all, 
> Can you do me a favor to review this patch. This patch use `ldp` to 
> implement String.compareTo.
>
> * We add a JMH test case 
> * Here is the result of this test case
>  
> Benchmark|(size)| Mode| Cnt|Score | Error  |Units 
> -|--|-||--||-
> StringCompare.compareLL   |  64  | avgt| 5  |7.992 | ±0.005|us/op
> StringCompare.compareLL   |  72  | avgt| 5  |15.029| ±0.006|us/op
> StringCompare.compareLL   |  80  | avgt| 5  |14.655| ±0.011|us/op
> StringCompare.compareLL   |  91  | avgt| 5  |16.363| ±0.12 |us/op
> StringCompare.compareLL   |  101 | avgt| 5  |16.966| ±0.007|us/op
> StringCompare.compareLL   |  121 | avgt| 5  |19.276| ±0.006|us/op
> StringCompare.compareLL   |  181 | avgt| 5  |19.002| ±0.417|us/op
> StringCompare.compareLL   |  256 | avgt| 5  |24.707| ±0.041|us/op
> StringCompare.compareLLWithLdp|  64  | avgt| 5  |8.001| ± 
> 0.121|us/op
> StringCompare.compareLLWithLdp|  72  | avgt| 5  |11.573| ±0.003|us/op
> StringCompare.compareLLWithLdp|  80  | avgt| 5  |6.861 | ±0.004|us/op
> StringCompare.compareLLWithLdp|  91  | avgt| 5  |12.774| ±0.201|us/op
> StringCompare.compareLLWithLdp|  101 | avgt| 5  |8.691 | ±0.004|us/op
> StringCompare.compareLLWithLdp|  121 | avgt| 5  |11.091| ±1.342|us/op
> StringCompare.compareLLWithLdp|  181 | avgt| 5  |14.64 | ±0.581|us/op
> StringCompare.compareLLWithLdp|  256 | avgt| 5  |25.879| ±1.775|us/op
> StringCompare.compareUU   |  64  | avgt| 5  |13.476| ±0.01 |us/op
> StringCompare.compareUU   |  72  | avgt| 5  |15.078| ±0.006|us/op
> StringCompare.compareUU   |  80  | avgt| 5  |23.512| ±0.011|us/op
> StringCompare.compareUU   |  91  | avgt| 5  |24.284| ±0.008|us/op
> StringCompare.compareUU   |  101 | avgt| 5  |20.707| ±0.017|us/op
> StringCompare.compareUU   |  121 | avgt| 5  |29.302| ±0.011|us/op
> StringCompare.compareUU   |  181 | avgt| 5  |39.31| ± 
> 0.016|us/op
> StringCompare.compareUU   |  256 | avgt| 5  |54.592| ±0.392|us/op
> StringCompare.compareUUWithLdp|  64  | avgt| 5  |16.389| ±0.008|us/op
> StringCompare.compareUUWithLdp|  72  | avgt| 5  |10.71 | ±0.158|us/op
> StringCompare.compareUUWithLdp|  80  | avgt| 5  |11.488| ±0.024|us/op
> StringCompare.compareUUWithLdp|  91  | avgt| 5  |13.412| ±0.006|us/op
> StringCompare.compareUUWithLdp|  101 | avgt| 5  |16.245| ±0.434|us/op
> StringCompare.compareUUWithLdp|  121 | avgt| 5  |16.597| ±0.016|us/op
> StringCompare.compareUUWithLdp|  181 | avgt| 5  |27.373| ±0.017|us/op
> StringCompare.compareUUWithLdp|  256 | avgt| 5  |41.74 | ±3.5  |us/op
> 
> From this table, we can see that in most cases, our patch is better than old 
> one.
> 
> Thank you for your review. Any suggestions are welcome.

This pull request has now been integrated.

Changeset: 6d1d4d52
Author:Wang Huang 
Committer: Hamlin Li 
URL:   
https://git.openjdk.java.net/jdk/commit/6d1d4d52928ed38bbc73ddcbede5389995a8e65f
Stats: 106 lines in 1 file changed: 39 ins; 40 del; 27 mod

8268231: Aarch64: Use ldp in intrinsics for String.compareTo

Co-authored-by: Wang Huang 
Co-authored-by: Sun Jianye 
Co-authored-by: Wu Yan 
Reviewed-by: ngasson, aph

-

PR: https://git.openjdk.java.net/jdk/pull/4722

Re: RFR: 8271598: CDS classlist file should support uber JARs

[Alan Bateman]

On Sat, 9 Oct 2021 00:15:43 GMT, Calvin Cheung  wrote:

> Currently, for archive classes for custom loaders, CDS supports the following 
> source locations in the classlist:

I've added the core-libs label to this issue as this will require wider 
discussion, detailed review of the classes that are being added to 
jdk.internal.misc, and a discussion as to whether this is the right place.

-

PR: https://git.openjdk.java.net/jdk/pull/5876