Re: RFR: 8309335: Get rid of use of reflection to call Thread.isVirtual() in nsk/jdi/EventRequestManager/stepRequests/stepreq001t.java [v2]

2023-08-14 Thread Alan Bateman
On Mon, 14 Aug 2023 19:13:28 GMT, Chris Plummer wrote: >> No need to use reflection to call Thread.isVirtual(). >> >> Tested by running Tier5 CI (filtered to run just svc tests). This resulted >> in running this test with and without JTREG_TEST_THREAD_FACTORY=Virtual and >> also with a variety

Re: RFR: 8282712: VMConnection.open() does not detect if VM failed to be created, resulting in NPE

2023-08-14 Thread Chris Plummer
On Mon, 14 Aug 2023 23:48:17 GMT, Serguei Spitsyn wrote: > Should the bug have the label "noreg-self"? There are two fixes of almost identical code. One is in test infra code, and thus maybe a noreg-self is warranted, but the other is in jdb, so I'm not sure what is best in that case. ---

Re: RFR: 8313357: Revisit requiring SA tests on OSX to either run as root or use sudo

2023-08-14 Thread David Holmes
On Fri, 11 Aug 2023 01:49:57 GMT, Chris Plummer wrote: > On OSX, don't require that sudo be used to launch SA tools if developer mode > is enabled. More details are in the CR. > > Due to this change, the following tests are no longer being skipped if the > host has developer mode is enabled.

Re: RFR: 8282712: VMConnection.open() does not detect if VM failed to be created, resulting in NPE

2023-08-14 Thread Serguei Spitsyn
On Sat, 12 Aug 2023 03:56:05 GMT, Chris Plummer wrote: > VMConnection.open() expects launchTarget(), attachTarget(), and > listentTarget() to either throw an exception or return a valid VirtualMachine > instance. Instead they were catching certain exceptions and returning null, > which resulte

Re: RFR: 8309335: Get rid of use of reflection to call Thread.isVirtual() in nsk/jdi/EventRequestManager/stepRequests/stepreq001t.java [v2]

2023-08-14 Thread Serguei Spitsyn
On Mon, 14 Aug 2023 19:13:28 GMT, Chris Plummer wrote: >> No need to use reflection to call Thread.isVirtual(). >> >> Tested by running Tier5 CI (filtered to run just svc tests). This resulted >> in running this test with and without JTREG_TEST_THREAD_FACTORY=Virtual and >> also with a variety

Re: RFR: JDK-8314197: AttachListener::pd_find_operation always returning nullptr

2023-08-14 Thread Serguei Spitsyn
On Mon, 14 Aug 2023 10:13:21 GMT, Matthias Baesken wrote: > AttachListener::pd_find_operation always returns nullptr and seems to be > obsolete, so we could probably remove it and clean up the coding a bit. Marked as reviewed by sspitsyn (Reviewer). - PR Review: https://git.openjd

Re: RFR: 8309335: Get rid of use of reflection to call Thread.isVirtual() in nsk/jdi/EventRequestManager/stepRequests/stepreq001t.java [v2]

2023-08-14 Thread Chris Plummer
> No need to use reflection to call Thread.isVirtual(). > > Tested by running Tier5 CI (filtered to run just svc tests). This resulted in > running this test with and without JTREG_TEST_THREAD_FACTORY=Virtual and also > with a variety of GCs and platforms. Chris Plummer has updated the pull req

Integrated: 8313854: Some tests in serviceability area fail on localized Windows platform

2023-08-14 Thread Kimura Yukihiro
On Mon, 7 Aug 2023 02:37:15 GMT, Kimura Yukihiro wrote: > I would like to fix this issue > because the svc jtreg test does not pass on localized Windows platform. > Testing: > all serviceability area tests (jdk_svc group). > > Could anyone review the fix please? > > Thanks, > Kimura Yukihiro

Re: RFR: 8309335: Get rid of use of reflection to call Thread.isVirtual() in nsk/jdi/EventRequestManager/stepRequests/stepreq001t.java

2023-08-14 Thread Alan Bateman
On Mon, 14 Aug 2023 17:31:24 GMT, Chris Plummer wrote: > No need to use reflection to call Thread.isVirtual(). > > Tested by running Tier5 CI (filtered to run just svc tests). This resulted in > running this test with and without JTREG_TEST_THREAD_FACTORY=Virtual and also > with a variety of G

Re: RFR: 8309335: Get rid of use of reflection to call Thread.isVirtual() in nsk/jdi/EventRequestManager/stepRequests/stepreq001t.java

2023-08-14 Thread Leonid Mesnik
On Mon, 14 Aug 2023 17:31:24 GMT, Chris Plummer wrote: > No need to use reflection to call Thread.isVirtual(). > > Tested by running Tier5 CI (filtered to run just svc tests). This resulted in > running this test with and without JTREG_TEST_THREAD_FACTORY=Virtual and also > with a variety of G

RFR: 8309335: Get rid of use of reflection to call Thread.isVirtual() in nsk/jdi/EventRequestManager/stepRequests/stepreq001t.java

2023-08-14 Thread Chris Plummer
No need to use reflection to call Thread.isVirtual(). Tested by running Tier5 CI (filtered to run just svc tests). This resulted in running this test with and without JTREG_TEST_THREAD_FACTORY=Virtual and also with a variety of GCs and platforms. - Commit messages: - No need to us

Re: RFR: JDK-8314197: AttachListener::pd_find_operation always returning nullptr

2023-08-14 Thread Chris Plummer
On Mon, 14 Aug 2023 10:13:21 GMT, Matthias Baesken wrote: > AttachListener::pd_find_operation always returns nullptr and seems to be > obsolete, so we could probably remove it and clean up the coding a bit. Marked as reviewed by cjplummer (Reviewer). - PR Review: https://git.openj

Re: RFR: 8314117: RISC-V: Incorrect VMReg encoding in RISCV64Frame.java

2023-08-14 Thread Feilong Jiang
On Mon, 14 Aug 2023 09:53:04 GMT, Vladimir Kempik wrote: > Please consider backporting this to 21u/17u if they are affected Sure, I'll backport it later. - PR Comment: https://git.openjdk.org/jdk/pull/15226#issuecomment-1677343419

Re: RFR: JDK-8314197: AttachListener::pd_find_operation always returning nullptr

2023-08-14 Thread Matthias Baesken
On Mon, 14 Aug 2023 10:13:21 GMT, Matthias Baesken wrote: > AttachListener::pd_find_operation always returns nullptr and seems to be > obsolete, so we could probably remove it and clean up the coding a bit. Hi David, thanks for the review ! If it is 'trivial' , afaik one review is sufficient,

Re: RFR: JDK-8314197: AttachListener::pd_find_operation always returning nullptr

2023-08-14 Thread David Holmes
On Mon, 14 Aug 2023 10:13:21 GMT, Matthias Baesken wrote: > AttachListener::pd_find_operation always returns nullptr and seems to be > obsolete, so we could probably remove it and clean up the coding a bit. Looks good and trivial. The last platform to have a non-empty implementation was Solari

RFR: JDK-8314197: AttachListener::pd_find_operation always returning nullptr

2023-08-14 Thread Matthias Baesken
AttachListener::pd_find_operation always returns nullptr and seems to be obsolete, so we could probably remove it and clean up the coding a bit. - Commit messages: - JDK-8314197 Changes: https://git.openjdk.org/jdk/pull/15265/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=

Re: RFR: 8314117: RISC-V: Incorrect VMReg encoding in RISCV64Frame.java

2023-08-14 Thread Vladimir Kempik
On Thu, 10 Aug 2023 14:01:25 GMT, Feilong Jiang wrote: > Hi, inspired by [JDK-8247351](https://bugs.openjdk.org/browse/JDK-8247351), > this patch fixes a VMReg encoding issue in `RISCV64Frame.java`. As the VMReg > has two slots in a 64-bit VM, the encoding of `fp` should be `8 << 1` instead >

Integrated: 8314117: RISC-V: Incorrect VMReg encoding in RISCV64Frame.java

2023-08-14 Thread Feilong Jiang
On Thu, 10 Aug 2023 14:01:25 GMT, Feilong Jiang wrote: > Hi, inspired by [JDK-8247351](https://bugs.openjdk.org/browse/JDK-8247351), > this patch fixes a VMReg encoding issue in `RISCV64Frame.java`. As the VMReg > has two slots in a 64-bit VM, the encoding of `fp` should be `8 << 1` instead >

Re: RFR: 8314117: RISC-V: Incorrect VMReg encoding in RISCV64Frame.java

2023-08-14 Thread Feilong Jiang
On Fri, 11 Aug 2023 06:50:59 GMT, Fei Yang wrote: >> Hi, inspired by [JDK-8247351](https://bugs.openjdk.org/browse/JDK-8247351), >> this patch fixes a VMReg encoding issue in `RISCV64Frame.java`. As the VMReg >> has two slots in a 64-bit VM, the encoding of `fp` should be `8 << 1` >> instead

Re: RFR: 8313357: Revisit requiring SA tests on OSX to either run as root or use sudo

2023-08-14 Thread Chris Plummer
On Mon, 14 Aug 2023 01:12:54 GMT, David Holmes wrote: > I would not be worried about trying to deal with a user that changes the > setting in that way. Test environments are expected to kept in a stable > condition. I think it is best to test for developer mode on each test run. The user might