Hi Dean,
Thank you for the reply.
The problem is I do not fully understand your suggestion,
especially the part
about caching the method,is_old() value in the
cache_jvmti_state().
This is a preliminary webrev where I tried to imple
Hi
Could you please review following fix which stop test execution if JVMTI
function returns error. The test fails anyway however using potentially
bad data in JVMTI function might cause misleading crash failures. The
hs_err will contains the stacktrace not with problem function but with
func
On 6/1/20 12:30,
serguei.spit...@oracle.com wrote:
Hi Fairoz,
It looks okay in general.
But I'm not sure this check is going to work.
The problem is the HeapwalkingDebuggee.useStrictCheck
method is invoked in the
Hi Daniil,
1. before the fix checkLiveThreads() tested
ThreadMXBean.getThreadCount(), but now as far as I see it tests
Thread.getAllStackTraces();
2.
237 private static void checkThreadIds() throws InterruptedException {
238 long[] list = mbean.getAllThreadIds();
239
240
Hi Ioi,
On 2/06/2020 8:56 am, Ioi Lam wrote:
On 5/31/20 11:14 PM, David Holmes wrote:
Hi Jiangli,
On 29/05/2020 9:02 am, Jiangli Zhou wrote:
(Looping in serviceability-dev@openjdk.java.net ...)
Hi David and Ioi,
On Wed, May 27, 2020 at 11:15 PM David Holmes
wrote:
Hi Jiangli,
On 28/0
On 5/31/20 11:14 PM, David Holmes wrote:
Hi Jiangli,
On 29/05/2020 9:02 am, Jiangli Zhou wrote:
(Looping in serviceability-dev@openjdk.java.net ...)
Hi David and Ioi,
On Wed, May 27, 2020 at 11:15 PM David Holmes
wrote:
Hi Jiangli,
On 28/05/2020 11:35 am, Ioi Lam wrote:
On 5/27/20
On 5/31/20 11:16 PM, serguei.spit...@oracle.com wrote:
Hi Dean,
To check the is_old as you suggest the target method has to be passed
to the cache_jvmti_state() as argument. Is it what you are suggesting?
I believe you can use use _task->method()->is_old(), as the ciEnv
already has the task.
Hi Daniil,
LGTM.
Thanks,
Serguei
On 5/29/20 16:28, Daniil Titov wrote:
Hi Alex and Serguei,
Please review a new version of the change [1] that makes sure that the test
counts
only the threads it creates and ignores Internal threads VM might create or
destroy.
Testing: Running this test i
Hi Fairoz,
It looks okay in general.
But I'm not sure this check is going to work.
The problem is the HeapwalkingDebuggee.useStrictCheck
method is invoked in the
context of the HeapwalkingDebugger
process, not the HeapwalkingDebuggee
Thanks, Chris!
Serguei
On 6/1/20 11:31, Chris Plummer wrote:
Hi Serguei,
Looks good.
thanks,
Chris
On 5/31/20 1:11 AM, serguei.spit...@oracle.com wrote:
Please, review a fix for small spec bug:
https://bugs.openjdk.java.net/browse/JDK-8221306
Webrev:
http://cr.openjdk.java.net/~sspitsyn/w
Hi Serguei,
Looks good.
thanks,
Chris
On 5/31/20 1:11 AM, serguei.spit...@oracle.com wrote:
Please, review a fix for small spec bug:
https://bugs.openjdk.java.net/browse/JDK-8221306
Webr
Hi Erik,
Thanks for the review, below is the updated webrev.
http://cr.openjdk.java.net/~fmatte/8243451/webrev.02/
Thanks,
Fairoz
> -Original Message-
> From: Erik Gahlin
> Sent: Monday, June 1, 2020 4:26 PM
> To: Fairoz Matte
> Cc: serviceability-dev@openjdk.java.net
> Subject: Re: RFR
Hi David,
I'll check with JetBrains on this.
Thank you to Dan and you for raising this concern.
The JetBrains use case you posted in the CSR looks like valid and useful.
Thanks,
Serguei
On 6/1/20 00:46, David Holmes wrote:
Hi Serguei,
Sorry, I think we have to re-think this change. As Dan fl
Hi David,
Thanks for reviewing the latest changes.
I'll create the follow on RFE's once the sealed classes code is in mainline.
Harold
On 5/31/2020 9:34 PM, David Holmes wrote:
Hi Harold,
On 1/06/2020 8:57 am, Harold Seigel wrote:
Thanks for the comments.
Here's version 3 of the JDK and VM
Hi Fairoz,
What I think you need to do is something like this:
if (className.equals("java.lang.Thread")) {
return !isJfrInitialized();
}
...
private static boolean isJfrInitialized() {
try {
Class clazz = Class.forName("jdk.jfr.FlightRecorder
Hi Erik,
Thanks for your quick response,
Below is the updated webrev to handle if jfr module is not present
http://cr.openjdk.java.net/~fmatte/8243451/webrev.01/
Thanks,
Fairoz
> -Original Message-
> From: Erik Gahlin
> Sent: Monday, June 1, 2020 2:31 PM
> To: Fairoz Matte
> Cc: service
Hi Fairoz,
If the test needs to run with builds where the JFR module is not present(?),
you need to do the check using reflection.
If not, looks good.
Erik
> On 1 Jun 2020, at 10:27, Fairoz Matte wrote:
>
> Hi,
>
> Please review this small test infra change to identify at runtime the JFR i
Hi,
Please review this small test infra change to identify at runtime the JFR is
active or not.
JBS - https://bugs.openjdk.java.net/browse/JDK-8243451
Webrev - http://cr.openjdk.java.net/~fmatte/8243451/webrev.00/
Thanks,
Fairoz
Hi Serguei,
Sorry, I think we have to re-think this change. As Dan flags in the CSR
request debuggers directly expose this API as part of the debugger
interface, so any change here will directly impact those tools. At a
minimum I think we would need to consult with the tool developers about
t
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 structure:
try {
// lots of thread state manipulation of target
}
finally {
thread.getLog();
}
and as David noticed in hi
20 matches
Mail list logo
