Hi Leonid,
I run the test with -XComp at Mach5 linux-x64-debug builds before and after the
changes the forwards VM and test options to j-* tools
and here is the difference in the execution times for some serviceability/sa
tests:
serviceability/sa/sadebugd/SADebugDTest.java, before : 2m 23s ,
Hi Chris and Serguei,
Please review a new version of the fix [1] that makes the tests try to repeat
the check only once.
Regarding the question Serguei asked:
> 97 while(true) {
> 113 if (mbeanCount * 2 == counterCount || isSecondAttempt) {
> 114 assertEqu
On 4/24/20 6:52 PM, Alex Menkov wrote:
Hi Chris,
On 04/24/2020 15:42, Chris Plummer wrote:
Hi Alex,
Overall it looks good, although I'm not so sure I agree with removing
getAppOutput(). It's a generally useful utility API. Seems it is
better off in LingeredApp.java rather than in the one tes
Hi Chris,
On 04/24/2020 15:42, Chris Plummer wrote:
Hi Alex,
Overall it looks good, although I'm not so sure I agree with removing
getAppOutput(). It's a generally useful utility API. Seems it is better
off in LingeredApp.java rather than in the one test that currently uses it.
To me the me
Adding hotspot-runtime-dev since logging is owned by runtime, not
serviceability.
Chris
On 4/24/20 3:41 PM, Leonid Mesnik wrote:
Looks good. (Need a 'R'eview.)
Leonid.
On Apr 24, 2020, at 3:30 PM, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00
8 lines chang
Hi Alex,
Overall it looks good, although I'm not so sure I agree with removing
getAppOutput(). It's a generally useful utility API. Seems it is better
off in LingeredApp.java rather than in the one test that currently uses it.
thanks,
Chris
On 4/24/20 3:17 PM, Alex Menkov wrote:
Hi all,
P
Looks good. (Need a 'R'eview.)
Leonid.
> On Apr 24, 2020, at 3:30 PM, Igor Ignatyev wrote:
>
> http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00
>> 8 lines changed: 0 ins; 6 del; 2 mod;
>
> Hi all,
>
> could you please review this small and trivial patch which updates
> serviceabilit
Looks good. (Not a 'R'eview though.)
Leonid.
> On Apr 24, 2020, at 3:17 PM, Alex Menkov wrote:
>
> Hi all,
>
> Please review the fix for
> https://bugs.openjdk.java.net/browse/JDK-8242522
> webrev:
> http://cr.openjdk.java.net/~amenkov/jdk15/LingeredApp_improve/webrev/
>
> The fix contains mi
http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00
> 8 lines changed: 0 ins; 6 del; 2 mod;
Hi all,
could you please review this small and trivial patch which updates
serviceability/logging/TestLogRotation.java test to pass both 'test.java.opts'
and not 'test.vm.opts' ? to do that, the pa
events with class filters.
Testing:
The mach5 job is in progress:
https://mach5.us.oracle.com/mdash/jobs/sspitsyn-HiddenClass-jdi-event-tests-20200424-0350-10464032
Thanks,
Serguei
mments
Testing:
Tested locally on Linux, mach5 test run is in
progress:
https://mach5.us.oracle.com/mdash/jobs/sspitsyn-HiddenClass-jvmti-test-20200424-1829-10
Hi all,
Please review the fix for
https://bugs.openjdk.java.net/browse/JDK-8242522
webrev:
http://cr.openjdk.java.net/~amenkov/jdk15/LingeredApp_improve/webrev/
The fix contains minor fixes/improvements for LingeredApp and tests
which use it. See jira for details.
Tested all tests which use L
llBytes
>- added ClassPrepare event
>- removed unneeded capability can_get_source_file_name
>- added more comments
>
> Testing:
> Tested locally on Linux, mach5 test run is in progress:
>
> https://mach5.us.oracle.com/mdash/jobs/sspitsyn-HiddenClass-j
Hi Patricio,
> > @Patricio, coming back to my question [1]:
> >
> > In the example you gave in your answer [2]: the java thread would execute a
> > vm operation during a
> > direct handshake operation, while the VMThread is actually in the middle of
> > a VM_HandshakeAllThreads
> > operation, wa
Hi Chris,
I agree with you. I will change the test to retry just once.
Thank you,
Daniil
From: Chris Plummer
Date: Friday, April 24, 2020 at 1:27 PM
To: Daniil Titov , "serguei.spit...@oracle.com"
, serviceability-dev
Subject: Re: RFR: 8242239: [Graal] javax/management/generifie
Hi Daniil,
I think a retry count more in line with our current expectations
would make more sense since it is deterministic how many retries
are might actually be needed. You just used a large number in case
more “lazy-registered” mbeans are added in the fu
vent
These tests are to provide a test coverage which was impossible to
provide with the jdb testing framework.
It includes ClassPrepare, Breakpoint and ModificationWatchpoint
events with class filters.
Testing:
The mach5 job is in progress:
https://mach5.us.oracle.com/mdash/jobs/sspitsyn-HiddenClass-jdi-event-tests-20200424-0350-10464032
Thanks,
Serguei
Hi Serguei and Chris,
Thank you for your comments.
I wanted to make the fix more generic and not limit it just to Graal
management bean. In this case we could expect that after the first retry is
triggered by Graal MBean registration some other “lazy-registered” MBean got
registered an
Hi Daniil,
Besides what Chris is pointed out the fix looks good.
Minor:
97 while(true) {
113 if(mbeanCount * 2 == counterCount || retryCounter++ > MAX_RETRY_ATTEMPT) {
114 assertEquals(mbeanCount * 2, counterCo
Tested locally on Linux, mach5 test run is in progress:
https://mach5.us.oracle.com/mdash/jobs/sspitsyn-HiddenClass-jvmti-test-20200424-1829-10485216
Thanks,
Serguei
Hi Daniil,
84 // If new MBean (e.g. Graal MBean) is registred while
the test is running names1,
106 // If new MBean (e.g. Graal MBean) is registred while
the test is running mbeans1,
registred -> registered
',' after "running"
Just wondering how you chose 10 as the
Hi Richard,
Just jumping into your last question for now. : )
On 4/24/20 1:08 PM, Reingruber, Richard wrote:
Hi Yasumasa, Patricio,
I will send review request to replace VM_SetFramePop to handshake in early next
week in JDK-8242427.
Does it help you? I think it gives you to remove workarou
Hi Yasumasa, Patricio,
> >> I will send review request to replace VM_SetFramePop to handshake in early
> >> next week in JDK-8242427.
> >> Does it help you? I think it gives you to remove workaround.
> >
> > I think it would not help that much. Note that when replacing
> > VM_SetFramePop with a
Hi Richard,
On 2020/04/24 23:44, Reingruber, Richard wrote:
Hi Yasumasa,
I will send review request to replace VM_SetFramePop to handshake in early next
week in JDK-8242427.
Does it help you? I think it gives you to remove workaround.
I think it would not help that much. Note that when repl
Hi Yasumasa,
> I will send review request to replace VM_SetFramePop to handshake in early
> next week in JDK-8242427.
> Does it help you? I think it gives you to remove workaround.
I think it would not help that much. Note that when replacing VM_SetFramePop
with a direct handshake
you could not
Hi Richard,
I will send review request to replace VM_SetFramePop to handshake in early next
week in JDK-8242427.
Does it help you? I think it gives you to remove workaround.
(The patch is available, but I want to see the result of PIT in this weekend
whether JDK-8242425 works fine.)
Thanks,
Hi Patricio, Vladimir, and Serguei,
now that direct handshakes are available, I've updated the patch to make use of
them.
In addition I have done some clean-up changes I missed in the first webrev.
Finally I have implemented the workaround suggested by Patricio to avoid
nesting the handshake
i
Hello,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8243500
http://cr.openjdk.java.net/~cjplummer/8243500/webrev.00/index.html
A couple years ago JDK-8214226 fixed an issue on Linux-x64 with SA stack
dumps not properly displaying the correct line number for the topmost
28 matches
Mail list logo
