Thank you, Serguei and JC, for reviewing this change!
Best regards,
Daniil
From: Jean Christophe Beyler
Date: Thursday, April 25, 2019 at 5:32 PM
To: Serguei Spitsyn
Cc: Daniil Titov , OpenJDK Serviceability
Subject: Re: RFR: 8222749:
vmTestbase/nsk/jdi/ThreadStartRequest
Please review the change that fixes an intermittent failure of the test when
running with Graal on.
The test creates exception requests for different kinds of exceptions and
errors, starts the debuggee that throws an exception, and listens for exception
events. If the number of received excepti
Please review the change that fixes this test when it is run with Graal on.
The test starts the debugee, creates multiple thread start requests, tells the
debuggee to start a new thread, and listens for the thread start events
received. If the number of the received thread start events doesn't m
ooks good to me too :-)
> Jc
>
> On Tue, Apr 9, 2019 at 7:01 PM <mailto:serguei.spit...@oracle.com>> wrote:
>
> Hi Daniil,
>
> It looks good.
>
> Thanks,
> Serguei
>
>
> On
Please review the change that fixes intermittent failure of the test when
running with Graal on.
The problem here is the similar to the one fixed in JDK-8218401, the callbacks
this test enables keep processing events and perform JVMTI calls after VM is
terminated. The fix ensures that the test
y behaviour before JDK-8205654 and with this fix.
>
> Thanks,
> David
>
> On 4/04/2019 5:02 am, Daniil Titov wrote:
>> Please review the change that makes jcmd process name matching on
>> Linux platform consistent with pre-existing behavio
Thank you, JC and David, for reviewing this change!
Best regards,
-Daniil
From: Jean Christophe Beyler
Date: Friday, April 5, 2019 at 9:40 AM
To: David Holmes
Cc: Daniil Titov , OpenJDK Serviceability
, Thomas Stüfe
Subject: Re: 8221730: jcmd process name matching broken
Hi Daniil
browse/JDK-8221730
Thanks,
Daniil
On 4/4/19, 7:15 PM, "David Holmes" wrote:
Hi Daniil,
On 5/04/2019 12:01 pm, Daniil Titov wrote:
> Hi David,
>
> I didn't use "hg rename". Now I recreated the patch using "hg rename"
for mo
titov/8221730/webrev.03/
Bug: https://bugs.openjdk.java.net/browse/JDK-8221730
Thanks!
Best regards,
Daniil
On 4/4/19, 5:45 PM, "David Holmes" wrote:
Hi Daniil,
On 5/04/2019 8:17 am, Daniil Titov wrote:
> Hi David and JC,
>
> Thank you for revi
h this fix.
Thanks,
David
On 4/04/2019 5:02 am, Daniil Titov wrote:
> Please review the change that makes jcmd process name matching on Linux
platform consistent with pre-existing behavior.
>
> On other platforms (and on Linux platform before changes [3]) the jcmd
u
Resending RFR 8221730 again as it seems as there is a limit to the line length
after which the mailer breaks the string and adds '!'. I apologize for
confusion it created.
Please review the change that makes jcmd process name matching on Linux
platform consistent with pre-existing behavior.
On
Resending the RFR for 8221730, since the formatting in the original email wad
corrupted.
Please review the change that makes jcmd process name matching on Linux
platform consistent with pre-existing behavior. On other platforms the jcmd
uses system property "sun.rt.javaCommand" (see sun.jvms
Please review the change that makes jcmd process name matching on Linux
platform consistent with pre-existing behavior.
On other platforms (and on Linux platform before changes [3]) the jcmd uses
system property "sun.rt.javaCommand" (see sun.jvmstat.monitor.
MonitoredVmUtil.mainClass(Monitore
Thank you, Chris and Gary, for review!
--Daniil
On 3/27/19, 12:19 PM, "Chris Plummer" wrote:
Looks good.
Chris
On 3/27/19 11:58 AM, Daniil Titov wrote:
> Hi Chris,
>
> Please review a new version of the webrev that corrects this.
&
gt; Thanks,
> Serguei
>
>
> On 3/26/19 20:32, Daniil Titov wrote:
>> Please review the change that fixes the test when running with Graal on.
>>
>> The problem here is the lack of synchronization when accessing the
>> internal data structure (
copyright year should not be changed when fixing copyright issues.
thanks,
Chris
On 3/27/19 11:18 AM, Daniil Titov wrote:
> Please review a trivial change that fixes the copyright headers in two
files.
>
> Webrev: http://cr.openjdk.java.net/~dtito
Please review a trivial change that fixes the copyright headers in two files.
Webrev: http://cr.openjdk.java.net/~dtitov/8221532/webrev.01
Bug: https://bugs.openjdk.java.net/browse/JDK-8221532
Thanks!
--Daniil
Please review the change that fixes the test when running with Graal on.
The problem here is the lack of synchronization when accessing the internal
data structure (the list of events) in the agent procedure and in the callbacks
the test enables. That results in the agent proc starts removing el
up
failing. You also don't know how JVMCI behavior might change in the
future, causing this test to fail again. Perhaps it is best not to run
these ResourceExhausted tests with JVMCI. Their reliability is dubious
enough already.
thanks,
Chris
On 3/22
increase the heap size?
thanks,
Chris
On 3/22/19 1:53 PM, Daniil Titov wrote:
> Please review the change that fixes the failure of the test when running
with Graal.
>
> The problem here is that the test consumes all memory before JVMCI
run
Please review the change that fixes the failure of the test when running with
Graal.
The problem here is that the test consumes all memory before JVMCI runtime is
fully initialized. As a result the call to
JVMCIRuntime::get_HotSpotJVMCIRuntime(CHECK_EXIT)
at src/hotspot/share/jvmci/jvmciCompile
Thank you, JC and Serguei, for reviewing this change.
Best regards,
Daniil
From: Jean Christophe Beyler
Date: Thursday, March 21, 2019 at 9:29 AM
To: Daniil Titov
Subject: Re: FW: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash
Hi Daniil,
Sorry yes it looks great to me
t if you lock a raw monitor in the event callbacks.
Thanks,
Serguei
On 3/20/19 14:58, Daniil Titov wrote:
> Hi Serguei,
>
> I think that just disabling event notifications inside VMDeath callback
still leaves a small window for VMDeath callback being called af
: Tuesday, March 19, 2019 at 7:17 PM
To: Daniil Titov , OpenJDK Serviceability
, Jean Christophe Beyler
Subject: Re: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash
Hi Daniil,
I'd keep the volatile modifier for callbacksEnabled to disable compiler
optimizations.
Otherwise, looks good
Thanks,
Serguei
On 3/15/19 16:08, Daniil Titov wrote:
> Please review the change that fixes 3 tests that intermittently fail with
JVMTI_ERROR_WRONG_PHASE error.
>
> The problem here is that the callbacks these tests enable keep processing
events and perf
, Mar 15, 2019 at 4:08 PM Daniil Titov wrote:
Please review the change that fixes 3 tests that intermittently fail with
JVMTI_ERROR_WRONG_PHASE error.
The problem here is that the callbacks these tests enable keep processing
events and perform JVMTI calls after VM is terminated. The fix makes
Please review the change that fixes 3 tests that intermittently fail with
JVMTI_ERROR_WRONG_PHASE error.
The problem here is that the callbacks these tests enable keep processing
events and perform JVMTI calls after VM is terminated. The fix makes these test
listen for VMDeath event and quick
Thank you, Dean, for reviewing this change.
--Daniil
On 3/12/19, 5:00 PM, "serviceability-dev-boun...@openjdk.java.net on behalf of
dean.l...@oracle.com" wrote:
Looks good and trivial.
dl
On 3/12/19 4:46 PM, Daniil Titov wrote:
> Please review a trivia
Please review a trivial change that removes test
vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003, recently fixed in
8218167, from ProblemList-graal.txt
Webrev: http://cr.openjdk.java.net/~dtitov/8220244/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8220244
Thanks!
--Daniil
This is consistent with how other system threads are handled, so it
looks good to me.
dl
On 3/11/19 4:32 PM, Daniil Titov wrote:
> Hi Dean, JC and Daniel,
>
> Thank you for reviewing this change. Based on the overall output it seems
as the common co
Hi Gary,
The fix looks good. However, since there are only two references
(debuggeeThread1 and debuggeeThread2) the test checks, an alternative to
catching and ignoring ObjectCollectedException could be just calling
disableCollection() on these two thread references when a breakpoint handle is
ganization: Oracle Corporation
Date: Thursday, March 7, 2019 at 12:19 PM
To: Daniil Titov , OpenJDK Serviceability
Subject: Re: RFR: 8218812:
vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed
There are other places where is_hidden_from_external_view() is use
Hi David,
Yes, the failure happened because Graal/JVMCI compiler threads were returned by
allThreads() and sometimes a new Graal thread got squeezed between allThreads()
calls.
Best regards,
Daniil
On 3/11/19, 12:31 AM, "David Holmes" wrote:
On 6/03/2019 7:59 am, Daniil T
Please review a change that fixes this test.
The problem here is that the test checks the number of threads and with Graal
on additional threads the test doesn't expect are started and cause the test
fail.
The fix introduces a new capability " can_show_compiler_threads" that affects
wh
Please disregard this email, somehow it got a wrong body..
Will resend the request later after dealing with my mail client.
Best regards,
Danill
On 3/7/19, 9:46 AM, "serviceability-dev on behalf of Daniil Titov"
wrote:
Resending review request with corrected subject...
Resending review request with corrected subject...
Please review a fix for this test that intermittently fails with Graal on.
The problem here is that the test does two consequent calls to
VirtualMachine.allThreads() and checks that the number of threads returned by
these calls is the same. W
Please review a change that fixes this test.
The problem here is that the test checks the number of threads and with Graal
on additional threads the test doesn't expect are started and cause the test
fail.
The fix introduces a new capability " can_show_compiler_threads" that affects
whether Ja
rguei
>
>
> On 3/5/19 1:59 PM, Daniil Titov wrote:
>> Please review a fix for this test that intermittently fails with
>> Graal on.
>>
>> The problem here is that the test does two consequent calls to
>> VirtualMachine.all
run these tests in different compiler modes?
Thanks,
Serguei
On 3/4/19 3:03 PM, Daniil Titov wrote:
> Hi Dean,
>
> You are right, test sp06t003 has the same problem. Please, review a new
version of the change that fixes both tests. I checked other tests
Please review a fix for this test that intermittently fails with Graal on.
The problem here is that the test does two consequent calls to
VirtualMachine.allThreads() and checks that the number of threads returned by
these calls is the same. With Graal on there is a chance that a new JVMCI
compi
part of the fix for
JDK-8051349, which was done a few months ago, so if the fix for
JDK-8051349 were not in place then your fix would not have worked.
thanks,
Chris
On 3/4/19 3:03 PM, Daniil Titov wrote:
> Hi Dean,
&g
thanks,
Chris
On 3/4/19 3:03 PM, Daniil Titov wrote:
> Hi Dean,
>
> You are right, test sp06t003 has the same problem. Please, review a new
version of the change that fixes both tests. I checked other tests and no more
tests use the this approach
imilar logic?
dl
On 3/1/19 8:33 PM, Daniil Titov wrote:
> Please review the change that fix intermittent failure for test
nsk/jvmti/scenarios/sampling/SP02/sp02t003 when running with Graal.
>
> The problem with the test here is that method checkThread() loo
Please review the change that fix intermittent failure for test
nsk/jvmti/scenarios/sampling/SP02/sp02t003 when running with Graal.
The problem with the test here is that method checkThread() looks for the test
method in the top "commonDepth" frames where "commonDepth" is a minimum of
"frameCou
Thank you Serguei and Chris for reviewing this change.
Best regards,
--Daniil
On 2/28/19, 10:19 AM, "serguei.spit...@oracle.com"
wrote:
Hi Daniil,
Thank you for explanation!
Thanks,
Serguei
On 2/28/19 08:50, Daniil Titov wrote:
&g
Did you miss to fix a timeout and comment in
VirtualMachine/suspend/suspend001.java
for breakpoint() the same way as it is done in
ThreadReference/suspend/suspend001.java?
Or it is intentional?
Thanks,
Serguei
On 2/27/19 21:51, Daniil Titov w
of the changes look good.
thanks,
Chris
On 2/27/19 5:44 PM, Daniil Titov wrote:
> Hi Chris and Serguei,
>
> Please review the new version of the fix that includes the changes Chris
suggested.
>
> Webrev: http://cr.openjdk.java
Hi Chris and Serguei,
Please review the new version of the fix that includes the changes Chris
suggested.
Webrev: http://cr.openjdk.java.net/~dtitov/8207367/webrev.04
Bug: https://bugs.openjdk.java.net/browse/JDK-8207367
Thanks!
--Daniil
On 2/27/19, 5:10 PM, "Daniil Titov" wrot
Hi Chris,
>>Is there a reason not to adjust it by argHandler.getWaitTime()?
I agree, for consistency it makes sense to adjust it by
argHandler.getWaitTime().
Thanks.
Daniil
On 2/27/19, 4:54 PM, "Chris Plummer" wrote:
On 2/27/19 4:09 PM, Daniil Titov wrote
itTime);
Thanks!
--Daniil
On 2/27/19, 3:08 PM, "Chris Plummer" wrote:
On 2/27/19 2:33 PM, Daniil Titov wrote:
> Hi Chris,
>
> The change in while loop in exclfilter001.java between the first and the
last revisions was to ensure that all events are
anged the behavior. Are these behavior
> differences necessary? Could you share code with the existing
> waitForCondition()?
thanks,
Chris
On 2/27/19 9:03 AM, Daniil Titov wrote:
> Hi Serguei and Chris,
>
> Thank you for reviewing this chang
: Oracle Corporation
Date: Tuesday, February 26, 2019 at 6:50 PM
To: Daniil Titov , Chris Plummer
, OpenJDK Serviceability
Subject: Re: RFR 8207367: 10 vmTestbase/nsk/jdi tests timed out when running
with jtreg
Hi Daniil,
It looks good to me.
I have some minor comments though.
http
anges look good.
thanks,
Chris
On 2/26/19 10:01 AM, Daniil Titov wrote:
> Hi Chris,
>
> Yes , it is correct. For example in this particular test the timeout is
expected (line 283 expects that breakpoint() returns returnCode3 that is set on
line 460 wh
tTimeout(waitTime*1000));
And I just noticed the space right after "remove". Can you remove it?
thanks,
Chris
On 2/25/19 6:57 PM, Daniil Titov wrote:
> Hi Chris,
>
> The timeout issue mentioned in the bug is about jtreg aborting the te
a shorter wait time?
Chris
On 2/25/19 5:04 PM, Daniil Titov wrote:
> Hi Chris,
>
> Forgot to answer to your another question:
> > > For these 3 tests the event wait timeout was reduced and
adjusted for test.timeout.factor:
>
bility that with a little bit of network
instability a packet gets lost and resend does not happen fast enough.
thanks,
Chris
On 2/25/19 4:32 PM, Daniil Titov wrote:
> Hi Chris,
>
> The code still waits for the whole total wait time. There is a whil
ed it in test runs but
I think it makes sense to adjust this test to take this potential case into
account. I will send an updated version of the patch soon.
Thanks!
Best regards,
Daniil
On 2/25/19, 12:21 PM, "Chris Plummer" wrote:
Hi Daniil,
On 2/23/19 1:02 PM,
Please review the change that fixes timeout issues for the following 10 tests
when running with jtreg and default timeout factor (1.0).
For the following 2 tests the event wait timeout was reduced and adjusted for
test.timeout.factor. Method receiveEvents(long,pattern) was fixed to ensure
that
Hi Alex,
+1
Thanks,
Daniil
On 2/11/19, 4:17 PM, "serviceability-dev on behalf of
serguei.spit...@oracle.com" wrote:
Hi Alex,
It looks Okay to me.
Thanks,
Serguei
On 2/11/19 15:20, Alex Menkov wrote:
> Hi all,
>
> Please review the fix for
Hi Alex,
The fix looks good for me.
Best regards,
Daniil
On 2/11/19, 3:59 PM, "serviceability-dev on behalf of Alex Menkov"
wrote:
Hi all,
please review the fix for
https://bugs.openjdk.java.net/browse/JDK-8218702
webrev:
http://cr.openjdk.java.net/~amenkov/RepStep_r
David Holmes" wrote:
Hi Daniil,
The fix seems reasonable.
These tests should all have been run before pushing JDK-8205654.
Thanks,
David
--
On 9/02/2019 3:37 pm, Daniil Titov wrote:
> Please review the change that fix the test failure.
Please review the change that fix the test failure.
The problem here is that the code in
sun.tools.common.ProcessArgumentMatcher.check() method was supposed to fallback
to the default mechanism for retrieving the main class name if
sun.tools.common.ProcessHelper (recently introduced in JDK-82
XX:+TieredCompilation -XX:+UseJVMCICompiler
-Djvmci.Compiler=graal") - 1m 21s
Best regards,
Daniil
On 2/7/19, 3:08 PM, "David Holmes" wrote:
Hi Daniil,
Thanks for the additional testing.
On 8/02/2019 3:52 am, Daniil Titov wrote:
> Hi Serguei and David,
>
think, it can be a good idea to add a simple tests for this
command-line processing.
It should save us from any surprises.
Thanks,
Serguei
On 2/4/19 13:24, Daniil Titov wrote:
> Hi Serguei,
>
> Thank you for reviewing this fix.
>
From: "serguei.spit...@oracle.com"
Date: Thursday, January 31, 2019 at 1:23 PM
To: David Holmes , Daniil Titov
, serviceability-dev
Subject: Re: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out
Hi Daniil,
I have some secondary comment on new file:
http://cr.open
Thank you Chris and JC for reviewing this change.
Best regards,
Daniil
From: Jean Christophe Beyler
Date: Tuesday, January 29, 2019 at 12:09 PM
To: Daniil Titov
Cc: OpenJDK Serviceability , Chris Plummer
Subject: Re: RFR 8163127: Debugger classExclusionFilter does not work correctly
Hi JC,
Could you please say are you OK with this new version of the fix?
Thanks!
--Daniil
On 1/26/19, 11:35 AM, "Chris Plummer" wrote:
Looks good.
thanks,
Chris
On 1/26/19 11:23 AM, Daniil Titov wrote:
> Hi Chris,
>
> Please r
disabling into
ConstantPool::klass_at_impl()
thanks,
Chris
On 1/24/19 10:38 AM, Daniil Titov wrote:
> Hi Chris and JC,
>
> Thank you for reviewing this change. Please review a new version of the
fix that uses
> the approach Chris sugge
cc()
>
> I wonder if it wouldn't be better if you moved the disabling into
> ConstantPool::klass_at_impl()
>
> thanks,
>
> Chris
>
> On 1/24/19 10:38 AM, Daniil Titov wrote:
>> Hi Chris and JC,
>>
>> T
next SINGLE_STEP
event after cp resolution is complete, and we are finally executing the
now resolved opc_new opcode.
I'm hoping Serguei and/or Alex can also comment on this, since I think
they were dealing with JvmtiHideSingleStepping() last month.
thanks,
-8205654
Thanks!
--Daniil
On 1/8/19, 6:05 PM, "David Holmes" wrote:
Hi Daniil,
Sorry this slipped through the Xmas break cracks :)
On 22/12/2018 12:04 pm, Daniil Titov wrote:
> Hi David and Serguei,
>
> Please review a new version of the fix that
Please review the change that fixes JDB stepping issue for a specific case when
the single step request was initiated earlier in the stack, previous calls were
for methods in the filtered classes (single stepping was disabled),
handleMethodEnterEvent() re-enabled stepping and the first bytecode
Hi Alex,
Looks good to me.
Thanks!
Best regards,
Daniil
On 1/17/19, 9:47 AM, "Alex Menkov" wrote:
Hi Daniil,
On 01/16/2019 22:27, Daniil Titov wrote:
> Hi Alex,
>
> The change looks good to me but I think the copyright comment needs to be
up
Hi Alex,
The change looks good to me but I think the copyright comment needs to be
updated for year 2019.
Thanks.
Best regards,
Daniil
On 1/16/19, 3:29 PM, "serviceability-dev on behalf of Alex Menkov"
wrote:
Hi all,
please review a fix for
https://bugs.openjdk.java.net/b
Thanks,
Daniil
On 11/29/18, 4:52 PM, "David Holmes" wrote:
Hi Daniil,
On 30/11/2018 7:30 am, Daniil Titov wrote:
> Thank you, David!
>
> The proposed fix didn't help. It still hangs at some occasions.
Additional tracing showed that when jcmd is inv
Hi Gary,
The fix looks good to me.
Thanks,
Daniil
On 12/12/18, 8:55 AM, "serviceability-dev on behalf of Gary Adams"
wrote:
After some testing with nsk verbose messages enabled,
it is clear that this test is failing in checkThreads when the
location did not match between the call
Thank you, Serguei,
I will correct it before pushing the changes in the repository.
Best regards,
Daniil
From: "serguei.spit...@oracle.com"
Date: Tuesday, December 4, 2018 at 7:49 PM
To: Daniil Titov , David Holmes
, serviceability-dev
, JC Beyler
Subject: Re: RFR 82
he thread to be suspended at the right place
>> + // when the top frame belongs to the test rather then to JVMCI code.
>>
>>
>>
>> No need in another webrev if you fix the comment.
>>
>> Thanks,
>> Serguei
>>
>>
>
the thread to be suspended at the right place
+ // when the top frame belongs to the test rather then to JVMCI code.
No need in another webrev if you fix the comment.
Thanks,
Serguei
On 12/4/18 10:24 AM, Daniil Titov wrote:
Hi Serguei and JC,
Thank you for reviewing this change. And
4:14 PM
To: Daniil Titov , serviceability-dev
Subject: Re: RFR 8214572: nsk/jvmti/unit/ForceEarlyReturn/earlyretbase should
not suspend the thread when the top frame executes JVMCI code
Hi Daniil,
It looks good in general.
I have two comments though.
-vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/ea
Please review the change for nsk/jvmti/unit/ForceEarlyReturn/earlyretbase test.
The problem here is that before doing an early force return the test doesn't
check that the test thread is suspended at a right place where the top frame
executes the test method rather than JVMCI code triggered by i
irtualMachinePids:154, ProcessArgumentMatcher (sun.tools.common)
main:83, JCmd (sun.tools.jcmd)
Best regards,
Daniil
On 11/29/18, 5:16 PM, "Chris Plummer" wrote:
Can you remind me why the test is trying to attach to all running java
processes.
Chris
On 11/29
Test$InvalidCommandTestProcess
TestJavaProcess.java:
39 public static void main(String argv[]) {
Nit: Should be "String[] argv" in Java style
Thanks,
David
On 10/11/2018 3:18 PM, Daniil Titov wrote:
> Please review the change that fixes se
nting that it was resolved with the JDK-8195627.
Thanks,
Serguei
On 11/9/18 12:26 PM, Daniil Titov wrote:
> Hi Dean,
>
> The blocking issue for suspended JVMCI compiler thread in case of Graal
and -XComp was recently solved in JDK-819562
Please review the change that fixes serviceability/dcmd/framework/* tests from
a time out. The fix for JDK-8166642 made serviceability/dcmd/framework/* tests
non-concurrent to ensure that they don't interact with each other and there are
no multiple tests running simultaneously since all they do
ionOption ||
>> CompileTheWorld || ReplayCompiles;
>>
>> So that probably means the test cannot be run with -Xcomp.
>>
>> dl
>>
>> On 11/8/18 3:12 PM, Daniil Titov wrote:
>>> The proposed fix for this case is to susp
/8/18 3:12 PM, Daniil Titov wrote:
> Hi Chris,
>
> You are right. There are different cases here. Please find them listed
below.
>
> 1. Test vmTestbase/nsk/jdi/stress/MonitorEvents/MonitorEvents002
> This test was actually fixed with JDK-8206086 changes.
add a suspend,
so it must have been in place already.
Maybe what's going on here is that there are actually 3 separate issues,
which is making it hard to figure out what the failure mode is for each
test, and how the changes are addressing it.
thanks,
C
> >>> shouldn't matter if there are GC's triggered by excessive object
> >>> allocations.
> >>>
> >>> I don't think the following check will always be valid. It may
be on
> >>> by default a
d. It may be on
>>> by default at some point:
>>>
>>> 651 public boolean isJVMCICompilerOn() {
>>> 652 String opts = argumentHandler.getLaunchOptions();
>>> 653 return opts.indexOf("-XX:+UseJVMCIC
It may be on by
default at some point:
651 public boolean isJVMCICompilerOn() {
652 String opts = argumentHandler.getLaunchOptions();
653 return opts.indexOf("-XX:+UseJVMCICompiler") >= 0;
654 }
thanks,
Chris
Please review the change that fixes several tests failing with
com.sun.jdi.ObjectCollectedException when running with Graal.
There main problem here is that with Graal on JVMCI Compiler threads in the
target VM create a lot of objects and sporadically trigger GC that results in
the objects crea
Please review the change that fixes the issue when the test hangs with Graal
and XComp mode on.
One of the test cases the test runs is to call
com.sun.jdi.VirtualMachine.redefineClasses() while the target VM is suspended.
The bytes passed to com.sun.jdi.VirtualMachine.redefineClasses() don't
Hi Gary,
This change looks OK to me.
Bets regards,
Daniil
On 10/23/18, 11:08 AM, "serviceability-dev on behalf of Gary Adams"
wrote:
Could I get a second reviewer for this change.
On 10/15/18, 3:16 PM, Chris Plummer wrote:
> Hi Gary,
>
> I think the simple prompt is
Chris Plummer" wrote:
Hi Daniil,
Looks good.
thanks,
Chris
On 10/19/18 4:01 PM, Daniil Titov wrote:
> Hi Chris,
>
> Please review an updated version of the fix that makes the tests to use a
custom pattern while waiting for the
: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
>
> Thanks!
> --Daniil
>
>
> On 10/19/18, 12:55 PM, "Chris Plummer" wrote:
>
> On 10/19/18 9:47 AM, Daniil
, 12:55 PM, "Chris Plummer" wrote:
On 10/19/18 9:47 AM, Daniil Titov wrote:
> Hi Gary and Chris,
>
> I am resending the previous email since the table in that email got
corrupted.
>
> Below is what output jdb prints when a breakpoint is hit dep
hread is
not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand)
method otherwise it would keep waiting for the full prompt and fail with the
timeout. Probably I am missing something here...
Thanks!
--Daniil
On 10/19/18, 9:27 AM, "Daniil Titov" wrote:
ands that
could be used with the wait for message in tests that need to
synchronize at a specific
point in the test sequence.
I don't think we see wait for simple prompt in any of the tests, because it
is not reliable enough.
On 10/18/18 11:53 AM, Daniil Titov
because there is too great a chance of false positives on such a small
marker.
On 10/17/18, 8:50 PM, Daniil Titov wrote:
> Hi Chris, Alex and JC,
>
> I created a separate issue to deal with "non-atomic" jdb output at
https://bugs.openjdk.java.net/br
201 - 300 of 381 matches
Mail list logo
