Re: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo [v6]

On Fri, 6 Aug 2021 09:50:54 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 |(s

Re: RFR: 8272836: Limit run time for java/lang/invoke/LFCaching tests

On Mon, 23 Aug 2021 11:33:35 GMT, Aleksey Shipilev wrote: > See the RFE for discussion. > > Current PR improves the test time like this: > > > $ make run-test TEST=java/lang/invoke/LFCaching/ > > # Before > real 3m51.608s > user 5m21.612s > sys 0m5.391s > > # After > real 1m13.606s > u

Re: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v2]

On Tue, 24 Aug 2021 20:21:52 GMT, Andrey Turbanov wrote: >> Collections.sort is just a wrapper, so it is better to use an instance >> method directly. > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > 8272863: Replace us

Re: Implementing MethodHandleProxies#asInterfaceInstance with hidden classes

- Original Message - > From: "-" > To: "Brian Goetz" , "core-libs-dev" > > Sent: Lundi 23 Août 2021 08:34:17 > Subject: Re: Implementing MethodHandleProxies#asInterfaceInstance with hidden > classes > Thanks for the quick reply! > > The main drawback, API wise, with LMF is that it doe

Re: Implementing MethodHandleProxies#asInterfaceInstance with hidden classes

On 25/08/2021 11:22, Remi Forax wrote: : In my opinion, what is missing is a java.lang.invoke.Proxy, the equivalent of java.lang.reflect.Proxy but using defineHiddenClass + a bootstrap method + method handles instead of the InvocationHandler + j.l.r.Method. With that, implementing java.lang.in

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

Hello Roger, On 24/08/21 8:14 pm, Roger Riggs wrote: Hi Jaikiran, Thanks for taking this on and getting it started. One use case of canonical storage is repeatable builds. It would be useful to identify the uses in the JDK that would need to be changed to use the new function. Surprisingly,

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

On 25/08/2021 11:51, Jaikiran Pai wrote: : 1. jdk.internal.vm.VMSupport#serializePropertiesToByteArray - Looking at the implementation in this method and as the name suggests, the Properties is being written out a byte array. This method gets called from native code, from what I can see. I

RFR: 8078641: MethodHandle.asTypeCache can retain classes from unloading

`MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle` and it can introduce a class loader leak through its `MethodType`. Proposed fix introduces a 2-level cache (1 element each) where 1st level can only contain `MethodHandle`s which are guaranteed to not introduce any de

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

Hi Jaikiran, I'm glad to see this issue finally getting some love and attention! :) I don't fully support those "inclinations" that say that the old API should not change. I think keeping the old random order of store() would mean a missed chance to do good, otherwise a lot of Java programs wi

Re: Implementing MethodHandleProxies#asInterfaceInstance with hidden classes

Thanks Remi, I strongly agree. In fact, with the ability to implement multiple methods in an invoke proxy (presumably through passing a list of name and handle pairs, and the impl method descriptors are stored in handles' method types), we can allow implementing any number of interfaces (even ones

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

On 2021-08-25 14:03, Magnus Ihse Bursie wrote: Hi Jaikiran, I'm glad to see this issue finally getting some love and attention! :) I don't fully support those "inclinations" that say that the old API should not change. I think keeping the old random order of store() would mean a missed cha

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

On 24/08/2021 15:07, Jaikiran Pai wrote: The java.util.Properties class allows the properties to be written out to a stream or through a writer. In its current form, the specification of these APIs state that a comment comprising of the current date is always written out. The spec doesn't make

Re: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v2]

On Wed, 25 Aug 2021 08:29:57 GMT, Daniel Fuchs wrote: >> Andrey Turbanov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8272863: Replace usages of Collections.sort with List.sort call in public >> java modules >> replace Collections.

Re: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v2]

On Wed, 25 Aug 2021 12:47:41 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/java/net/URLPermission.java line 222: >> >>> 220: >>> 221: List l = normalizeMethods(methods); >>> 222: l.sort(null); >> >> I am not opposed to this change, but I find this is slightly more

Re: JPackage and ask for microphone permissions broken on OSX...

> On Aug 24, 2021, at 6:52 AM, Andy Herrick wrote: > > One final thing to note, MacOS keeps track of what you have ever previously > granted microphone permission to (and will never ask again) based on the mac > package identifier (which defaults to the main class name), so I explicitly > s

Re: JPackage and ask for microphone permissions broken on OSX...

> On Aug 25, 2021, at 8:40 AM, Alan Snyder wrote: > > > >> On Aug 24, 2021, at 6:52 AM, Andy Herrick wrote: >> >> One final thing to note, MacOS keeps track of what you have ever previously >> granted microphone permission to (and will never ask again) based on the mac >> package identif

Re: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v3]

> Collections.sort is just a wrapper, so it is better to use an instance method > directly. Andrey Turbanov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. -

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

Hi, For the occasional human reader of a property file, a deterministic order would make them easier to use as well.  The natural sort order of the keys as String would be suitable. I'd support changing the order written without changing the API. Load and other readers of property files have

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

Hi, Not all properties file might benefit from being sorted in key ordering. Think for instance about the logging.properties file - where you would certainly want to keep the original ordering. That said - we rarely store() a logging properties file, and if we stored it, key might appear in ran

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

On 25/08/21 5:33 pm, Magnus Ihse Bursie wrote: ... The problem is with the time stamp, which the spec states should be present. I understand why changing this might need a new method. But I think we should try to steer users to this new method. Otherwise it is likely not to be used by those

Re: [External] : Re: JPackage and ask for microphone permissions broken on OSX...

On 8/25/2021 9:40 AM, Alan Snyder wrote: On Aug 24, 2021, at 6:52 AM, Andy Herrick > wrote: One final thing to note, MacOS keeps track of what you have ever previously granted microphone permission to (and will never ask again) based on the mac package iden

Re: RFR: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong

On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. When instant seconds and zone > co-exist in parsed data, instant seconds was not resolved correctly from them. Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.

Re: [External] : Re: JPackage and ask for microphone permissions broken on OSX...

Good to hear! > On Aug 25, 2021, at 7:35 AM, Andy Herrick wrote: > > > On 8/25/2021 9:40 AM, Alan Snyder wrote: >> >> >>> On Aug 24, 2021, at 6:52 AM, Andy Herrick >> > wrote: >>> >>> One final thing to note, MacOS keeps track of what you have ever previously

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

On 25/08/21 6:21 pm, Alan Bateman wrote: On 24/08/2021 15:07, Jaikiran Pai wrote: The java.util.Properties class allows the properties to be written out to a stream or through a writer. In its current form, the specification of these APIs state that a comment comprising of the current date i

Re: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1

On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev wrote: > See the bug report for more details. I would appreciate if people with their > corporate testing systems would run this through their systems to avoid > surprises. (ping @RealCLanger, @iignatev). the testing in our infra returned gree

Re: RFR: 8272836: Limit run time for java/lang/invoke/LFCaching tests

On Mon, 23 Aug 2021 11:33:35 GMT, Aleksey Shipilev wrote: > See the RFE for discussion. > > Current PR improves the test time like this: > > > $ make run-test TEST=java/lang/invoke/LFCaching/ > > # Before > real 3m51.608s > user 5m21.612s > sys 0m5.391s > > # After > real 1m13.606s > u

Re: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v2]

On Wed, 25 Aug 2021 02:17:12 GMT, Mandy Chung wrote: >> Hi Mandy, I have changed the implementation of the method to explicitly >> require all arguments but lookup to be non-null as suggested by Brian. I >> have also covered, I think, all the missing test cases in test >> `ObjectMethodsTest`,

Re: RFR: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong

On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. When instant seconds and zone > co-exist in parsed data, instant seconds was not resolved correctly from them. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.ne

Re: RFR: 8272836: Limit run time for java/lang/invoke/LFCaching tests

On Wed, 25 Aug 2021 15:56:39 GMT, Igor Ignatyev wrote: > so instead of using the hardcode limit, I'd prefer to adjust the > multiplication, `0.25` will give you the same 60s w/ current default timeout > factor. Oh, okay, good point. I changed multiplier from `0.9` to `0.2`. That works out to

Re: RFR: 8272836: Limit run time for java/lang/invoke/LFCaching tests [v2]

> See the RFE for discussion. > > Current PR improves the test time like this: > > > $ make run-test TEST=java/lang/invoke/LFCaching/ > > # Before > real 3m51.608s > user 5m21.612s > sys 0m5.391s > > # After > real 1m13.606s > user 2m26.827s > sys 0m4.761s Aleksey Shipilev has update

Re: RFR: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong

On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. When instant seconds and zone > co-exist in parsed data, instant seconds was not resolved correctly from them. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.

Re: RFR: 8272836: Limit run time for java/lang/invoke/LFCaching tests [v2]

On Wed, 25 Aug 2021 16:31:50 GMT, Aleksey Shipilev wrote: >> See the RFE for discussion. >> >> Current PR improves the test time like this: >> >> >> $ make run-test TEST=java/lang/invoke/LFCaching/ >> >> # Before >> real 3m51.608s >> user 5m21.612s >> sys 0m5.391s >> >> # After >> real 1m1

Re: RFR: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError [v4]

> Change #3294 helps to avoid `AnnotaionFormatException` in > `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. > While it fixes the case with e.g. `Runnable` that generates the synthetic > method without parameters, validation still fails on synthetic methods that

Re: RFR: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError [v4]

On Wed, 25 Aug 2021 17:53:52 GMT, Sergei Ustimenko wrote: >> Change #3294 helps to avoid `AnnotaionFormatException` in >> `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. >> While it fixes the case with e.g. `Runnable` that generates the synthetic >> method wit

Re: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v2]

On 8/25/21 12:08 PM, Vicente Romero wrote: On Wed, 25 Aug 2021 02:17:12 GMT, Mandy Chung wrote: Hi Mandy, I have changed the implementation of the method to explicitly require all arguments but lookup to be non-null as suggested by Brian. I have also covered, I think, all the missing test

Re: RFR: 8272861: Add a micro benchmark for vector api [v3]

On Tue, 24 Aug 2021 20:49:52 GMT, Sandhya Viswanathan wrote: >> This pull request adds a micro benchmark for Vector API. >> The Black Scholes algorithm is implemented with and without Vector API. >> We see about ~6x gain with Vector API for this micro benchmark using 256 bit >> vectors. > > San

Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v2]

> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified > unexpected messages from a child Java VM > as the cause of the test failure. Attempts to control the output of the > child VM have failed, the VM is unrepentant . > > There is no functionality in the child except to

Re: what does the spec say about file paths that are too long?

Lacking any new data, I guess it is fair to assume that there is no specification for the behavior of methods that use file paths that are too long, and presumably no tests, either. So the next question is whether there should be such a specification. I think there should be a specification bec

RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation

Get rid of WeakReference-based logic in DirectMethodHandle::checkInitialized() and reimplement it with `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`. The key observation is that `Unsafe::ensureClassInitialized()` does not block the initializing thread. Also, removed `Unsafe::sho

Re: RFR: 8272836: Limit run time for java/lang/invoke/LFCaching tests [v2]

On Wed, 25 Aug 2021 16:31:50 GMT, Aleksey Shipilev wrote: >> See the RFE for discussion. >> >> Current PR improves the test time like this: >> >> >> $ make run-test TEST=java/lang/invoke/LFCaching/ >> >> # Before >> real 3m51.608s >> user 5m21.612s >> sys 0m5.391s >> >> # After >> real 1m1

Re: what does the spec say about file paths that are too long?

I think what constitutes a „too long path“ is highly environment and data dependent. For some OS it depends on configuration, version, filesystem type, mount structure, encoding, canonicalisation and API used. Java would have a really hard time to codify this all. So the current solution „try th

Re: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v2]

On 8/25/21 4:45 PM, Mandy Chung wrote: On 8/25/21 12:08 PM, Vicente Romero wrote: On Wed, 25 Aug 2021 02:17:12 GMT, Mandy Chung wrote: Hi Mandy, I have changed the implementation of the method to explicitly require all arguments but lookup to be non-null as suggested by Brian. I have al

Re: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v3]

> Please review this simple PR along with the associated CSR. The PR is > basically adding a line the the specification of method > `java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a > NPE will be thrown. > > TIA > > link to the [CSR](https://bugs.openjdk.java.net/bro

Re: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation

On Wed, 25 Aug 2021 22:05:24 GMT, Vladimir Ivanov wrote: > The key observation is that `Unsafe::ensureClassInitialized()` does not block > the initializing thread. I'm unclear exactly what that statement is meant to indicate. The thread actually running "clinit" does not block due to the init

Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v2]

On Wed, 25 Aug 2021 21:45:57 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified >> unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the >> child VM have failed, the VM is unrepent

Re: RFR: 8272836: Limit run time for java/lang/invoke/LFCaching tests [v2]

On Wed, 25 Aug 2021 16:31:50 GMT, Aleksey Shipilev wrote: >> See the RFE for discussion. >> >> Current PR improves the test time like this: >> >> >> $ make run-test TEST=java/lang/invoke/LFCaching/ >> >> # Before >> real 3m51.608s >> user 5m21.612s >> sys 0m5.391s >> >> # After >> real 1m1

Integrated: 8272836: Limit run time for java/lang/invoke/LFCaching tests

On Mon, 23 Aug 2021 11:33:35 GMT, Aleksey Shipilev wrote: > See the RFE for discussion. > > Current PR improves the test time like this: > > > $ make run-test TEST=java/lang/invoke/LFCaching/ > > # Before > real 3m51.608s > user 5m21.612s > sys 0m5.391s > > # After > real 1m13.606s > u

Re: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform [v2]

On Wed, 4 Aug 2021 07:25:06 GMT, Masanori Yano wrote: >> Hi all, >> >> Could you please review the 8269373 bug fixes? >> >> These tests call java.lang.ProcessBuilder in direct, so not used jtreg >> command option. To run non-localized tests, -Duser.language=en and >> -Duser.country=US options