Please review the change that fix the JDI test when running with Graal.
The problem here is that the test verifies that a class prepare event is
generated when the target VM loads a specific test class, but with Graal turned
on additional class prepare events are generated by the compiler thread
Please review this fix which eliminates some docker/cgroup test failures when
running on older
Linux kernels with missing cgroup metric files.
BUGS:
https://bugs.openjdk.java.net/browse/JDK-8206456
WEBREV:
http://cr.openjdk.java.net/~bobv/8206456/webrev/
This fix has been verified by the report
Hi all,
here is an updated webref at
http://cr.openjdk.java.net/~simonis/webrevs/2018/8205608.v2/
I've converted the shell based test to a Java one, which had the nice side
effect of speeding it up (now takes ~1 second runtime).
The fix itself is mainly unchanged, but I've added the variable
Hi Bob, looks good (I am not a Reviewer however) !
The reported issues occured on a SUSE Linux 12 SP1 system , where
/sys/fs/cgroup/cpuset/cpuset.effective_cpus and
/sys/fs/cgroup/cpuset/cpuset.effective_memsare not present .
I applied Bobs patch , now the jdk/internal/pl
A race condition exists between the debugger and the debuggee.
The first test thread is started with SUSPEND_NONE policy set.
While processing the thread start event the debugger captures
an initial set of thread suspend counts and resumes the
debuggee vm. If the debuggee advances quickly it reac
Hi Daniil,
Not sure, I fully understand the fix.
So, let's start from some questions.
Why the DefaultClassPrepareEventListener is
needed?
Is it not enough to filter out the other threads in the
ClassPrepareEventListener.eventReceived(
+1
--alex
On 07/16/2018 12:58, [email protected] wrote:
Hi Jc,
It looks good to me.
Thanks,
Serguei
On 7/16/18 10:58, JC Beyler wrote:
Hi all,
Small RFR to update a HeapMonitor test that had two issues: a test was
wrong and the test was not allocating enough to get to an expected
Looks good to me as well
--alex
On 07/16/2018 16:06, [email protected] wrote:
Hi Jc,
It looks good to me.
Thanks,
Serguei
On 7/16/18 12:37, JC Beyler wrote:
Hi all,
Small RFR to update two HeapMonitor tests to remove test failures when
resetting a test data structure and assumin
Hi Serguei,
The test starts the event handler (nsk.share.jdi.EventHandler) and then
iterates several times calling testSourceFilter() method passing there
different parameters. The testSourceFilter() method does the following:
1. creates a ClassPrepareRequest object
2. registers ne
Hi Alex,
Thanks for the review!
Here is now the new webrev, ready for a push:
http://cr.openjdk.java.net/~jcbeyler/8205541/webrev.03/
Thanks all,
Jc
On Tue, Jul 17, 2018 at 2:48 PM Alex Menkov
wrote:
> Looks good to me as well
>
> --alex
>
> On 07/16/2018 16:06, [email protected] wro
The changes look good to me.
--alex
On 07/16/2018 16:10, [email protected] wrote:
Hi all,
We need at least one more review before pushing it.
Thanks,
Serguei
On 7/16/18 16:07, JC Beyler wrote:
Hi all,
The CSR has recently been approved, could someone else review the spec
update
Thanks a lot for reviews, Alex!
Serguei
On 7/17/18 15:38, Alex Menkov wrote:
The changes look good to me.
--alex
On 07/16/2018 16:10, [email protected] wrote:
Hi all,
We need at least one more review before pushing it.
Thanks,
Serguei
On 7/16/18 16:07, JC Beyler wrote:
Hi all,
Hi Daniil,
Thank you for clarification and the webrev update!
I still have a couple of questions though.
I'd suggest more simple approach like below:
154 public boolean eventReceived(Event event) {
155 if (event instanceof Class
On 7/17/18 7:00 AM, Bob Vandette wrote:
Please review this fix which eliminates some docker/cgroup test failures when
running on older
Linux kernels with missing cgroup metric files.
BUGS:
https://bugs.openjdk.java.net/browse/JDK-8206456
WEBREV:
http://cr.openjdk.java.net/~bobv/8206456/webr
Hi Serguei,
We could combine both listeners in one but in this case this listener should be
DefaultClassPrepareEventListener that is registered only once at the very
beginning of the whole test. We will also need to add a method to reset
eventReceived counter between invocations of testSource
Hi all,
Here is the webrev:
http://cr.openjdk.java.net/~jcbeyler/8205652/webrev.02/
Thanks for the reviews and future push!
Jc
On Tue, Jul 17, 2018 at 2:29 PM Alex Menkov
wrote:
> +1
>
> --alex
>
> On 07/16/2018 12:58, [email protected] wrote:
> > Hi Jc,
> >
> > It looks good to me.
>
Pushed.
Thanks!
Serguei
On 7/17/18 17:54, JC Beyler wrote:
Hi all,
Here is the webrev:
http://cr.openjdk.java.net/~jcbeyler/8205652/webrev.02/
Thanks for the review
Hi Jc,
Are you waiting for more reviewers?
Otherwise, could you send me a patch for push please?
Thanks,
Serguei
On 7/17/18 15:38, Alex Menkov wrote:
The changes look good to me.
--alex
On 07/16/2018 16:10, [email protected] wrote:
Hi all,
We need at least one more review before
Hi Serguei,
Please review a new version of the patch.
Webrev: http://cr.openjdk.java.net/~dtitov/8204695/webrev.03
Bug: https://bugs.openjdk.java.net/browse/JDK-8204695
Thanks!
Best regards,
Daniil
From: "[email protected]"
Date: Tuesday, July 17, 2018 at 4:53 PM
To:
Hi Daniil,
It looks good to me.
Thank you for the update.
How many tests are depending on this class?
Could we say that all the nsk/jdi/ClassPrepareRequest tests
need to be checked that there are no regressions?
Thanks,
Sergu
Pushed.
Thanks!
Serguei
On 7/17/18 20:05, JC Beyler wrote:
Hi Serguei,
No I was waiting for the other patches to be pushed (thank
you for doing it). Now that it is done, I prepared this one
Hi Serguei,
The changes are in the one test class
vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter002/addSourceNameFilter002.java
so they affect only this single test. No other tests depend on this class.
Best regards,
Daniil
From: "serguei.spit...@or
Hi Daniil,
Good.
Thanks,
Serguei
On 7/17/18 20:32, Daniil Titov wrote:
Hi Serguei,
The changes are in the one test class
vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSou
Hi Ralf,
A few comments below, but overall looks good:
27 * @summary get stack trace for large stacks took too long.
How about "Test that getting the stack trace for a very large stack does
not take too long".
The max number of frames you'll test for is 100M, but the stack size is
set to
Hi Gary,
I've been having trouble following the control flow of this test. One
thing I've stumbled across is the following:
/* A debuggee class must define 'methodForCommunication'
* method and invoke it in points of synchronization
* with a debugger.
25 matches
Mail list logo
