Please, review a fix for:
https://bugs.openjdk.java.net/browse/JDK-8196450
CSR draft (one CSR reviewer is needed before finalizing it):
https://bugs.openjdk.java.net/browse/JDK-8246540
Webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2020
Hi Alex,
Please review a new version of the webrev [1] that no longer uses
waitTillEquals() method.
[1] http://cr.openjdk.java.net/~dtitov/8131745/webrev.04/
[2] https://bugs.openjdk.java.net/browse/JDK-8131745
Thank you,
Daniil
On 6/3/20, 4:42 PM, "Alex Menkov" wrote:
Hi again Daniil,
Hi Richard,
The mach5 test run is good.
Thanks,
Serguei
On 6/2/20 10:57, Reingruber, Richard wrote:
Hi Serguei,
This looks good to me.
Thanks!
From an earlier mail:
I'm thinking it would be more safe to run full tier5.
I guess we're done with reviewing. Would be good if you could run
Hi David,
> So all such tests should be using driver mode, and further the VMs they then
> exec don't use any of the APIs that include the jtreg test arguments.
correct, and 8151707's subtasks are going to mark only such tests (and tests
which should be using driver-mode, but can't due to exter
On 6/3/20 16:10, David Holmes wrote:
Hi Serguei,
On 4/06/2020 6:41 am, serguei.spit...@oracle.com wrote:
Hi David,
The JetBrains confirmed:
Ability to select the exception is a valuable feature they provide.
Throwing only ThreadDeath is almost useless.
So, should I close this and rela
Hi again Daniil,
On 06/03/2020 16:31, Daniil Titov wrote:
Hi Alex,
Thanks for this suggestion. You are right, we actually don't need this
waitForAllThreads() method.
I will include this change in the new version of the webrev.
207 int diff = numNewThreads - numTerminatedThrea
Hi Alex,
Thanks for this suggestion. You are right, we actually don't need this
waitForAllThreads() method.
I will include this change in the new version of the webrev.
> 207 int diff = numNewThreads - numTerminatedThreads;
> 208 long threadCount = mbean.getThreadCoun
Hi Serguei,
On 4/06/2020 6:41 am, serguei.spit...@oracle.com wrote:
Hi David,
The JetBrains confirmed:
Ability to select the exception is a valuable feature they provide.
Throwing only ThreadDeath is almost useless.
So, should I close this and related JDI/JDWP enhancements as WNF?
Yes.
Hi Dean,
Thank you a lot for the review!
I hope, Christian will have a chance to look at it.
Thanks,
Serguei
On 6/3/20 14:56, Dean Long wrote:
Hi
Serguei, I like the latest changes so that JVMCI matches C2.
Hi Igor,
On 4/06/2020 7:30 am, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8246494/webrev.00
70 lines changed: 66 ins; 0 del; 4 mod
Hi all,
could you please review the patch which introduces a new @requires property to
filter out the tests which ignore externally provided JV
Hi Daniil,
couple notes:
198 waitForThreads(numNewThreads, numTerminatedThreads);
You don't actually need any wait here.
Test cases wait until all threads are in desired state
(checkAllThreadsAlive uses startupCheck, checkDaemonThreadsDead and
checkAllThreadsDead use join())
205
Hi Serguei, I like the latest changes so that JVMCI matches C2. Please
get another review because this is not a trivial change.
dl
On 6/3/20 10:06 AM, serguei.spit...@oracle.com wrote:
Hi Dean,
The updated webrev is:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/kitchensink-comp.3/
Proba
http://cr.openjdk.java.net/~iignatyev//8246494/webrev.00
> 70 lines changed: 66 ins; 0 del; 4 mod
Hi all,
could you please review the patch which introduces a new @requires property to
filter out the tests which ignore externally provided JVM flags?
the idea behind this patch is to have a way t
Hi Chris,
> Do you think 60 seconds is a bit long? Isn't the expectation that the join
> should happen almost immediately or not at all?
In case if an exception is thrown in the try block after the thread is started
and before it is moved in the terminated state the join never happens at al
PING: One more review for this fix is
needed.
Thanks,
Serguei
On 6/3/20 09:52, serguei.spit...@oracle.com wrote:
Thank you a lot for review, Coleen!
Serguei
On 6/3/20 08:50, coleen.phillim...@o
Hi David,
The JetBrains confirmed:
Ability to select the exception is a valuable feature they provide.
Throwing only ThreadDeath is almost useless.
So, should I close this and related JDI/JDWP enhancements as WNF?
Thanks,
Serguei
On 6/1/20 08:30, serguei.spit...@oracle.com wrote:
Hi Davi
Hi Daniil,
Ok, I misread getLog() and see that is now always returns the log.
Do you think 60 seconds is a bit long? Isn't the expectation that
the join should happen almost immediately or not at all?
I don't think you need a separate bug, but you sh
Hi Chris,
I was not able to reproduce the original issue anymore in Mach5. However, the
test itself has a potential for a deadlock (that was also reported) and in the
proposed change we fix it. The log still should be printed and the expectation
is that we will be able to see the underlying
Hi Jiangli,
My point is, if we are introducing a behavioral change in an
optimization, it should be carefully reviewed. That's a rule we have
followed all along.
Can we first push your change without the JVMTI behavioral change, and
discuss the JVMTI behavioral change separately?
If I unde
On 6/1/20 12:10 AM, David Holmes wrote:
Hi
Daniil,
On 30/05/2020 10:07 am, Daniil Titov wrote:
Please review a change [1] that fixes an
intermittent test timeout.
The main logic of the test has this basic
Hi Dean,
The updated webrev is:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/kitchensink-comp.3/
Probably, the JVMCI part can be simplified.
Only the compile_state line has to be moved up:
+JVMCICompileState compile_stat
Thank you a lot for review, Coleen!
Serguei
On 6/3/20 08:50, coleen.phillim...@oracle.com wrote:
Hi Serguei,
This change looks great. Thank you for fixing this!
Coleen
On 5/28/20 7:16 PM, serguei.spit...@oracle.com wrot
Hi Serguei,
This change looks great. Thank you for fixing this!
Coleen
On 5/28/20 7:16 PM, serguei.spit...@oracle.com wrote:
Hi Coleen,
The updated webrev version is:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/jvmti-redef.3/
It has your suggestions addressed:
- remove log_is_enabled
On 5/28/20 5:44 PM, serguei.spit...@oracle.com wrote:
Hi Coleen,
Thank you a lot for reviewing this!
On 5/28/20 12:48, coleen.phillim...@oracle.com wrote:
Hi Serguei,
Sorry for the delay reviewing this again.
On 5/18/20 3:30 AM, serguei.spit...@oracle.com wrote:
Hi Coleen and potential re
Hi Ralf,
I had a look at your change, webrev.3.
Thanks for contributing this!
Overall, a nicely engineered piece of work. Thus, my
comments are mostly minor details:
diagnosticCommand.hpp
ok.
diagnosticCommand.cpp:
l.510
I would be a bit more precise in the comment:
..."9 the slowest level
25 matches
Mail list logo
