Thanks for feedback.
I checked time execution. Tests takes several seconds longer on the hosts which
compress cores. Also, tests TestJmapCore.java, TestJmapCoreMetaspace.java are
slow and not included in tier1_serviceability anyway.
Updated version here. I fixed it accordingly with your comment
Hi Igor,
On 9/27/19 3:49 AM, Igor Ignatev wrote:
Hi Per,
On Sep 26, 2019, at 2:32 PM, Per Liden wrote:
Hi Igor,
I don't think it belongs in the problem list, for two reasons:
1) The test doesn't fail because of a bug. It fails because ZGC doesn't
currently support that use case. In other
Hi Andrew,
That is Okay.
Thank you for sharing it!
Thanks,
Serguei
On 9/26/19 05:35, Andrew Leonard wrote:
I think given the complexities involved in trying to make the JDI
connector's "thread-safe", i'm thinking now it's probably best leaving
this as-is. As Alan pointed out the java doc doe
Hi Leonid,
On 27/09/2019 7:18 am, Leonid Mesnik wrote:
Hi
Some hosts used for JDK testing have customized core dump settings. They
compress core files saved in current directory on-the-fly to reduce
required disk space.
This fix adopt several SA tests, trying to unpack core.pid.gz before
tes
Hi Per,
> On Sep 26, 2019, at 2:32 PM, Per Liden wrote:
>
> Hi Igor,
>
> I don't think it belongs in the problem list, for two reasons:
>
> 1) The test doesn't fail because of a bug. It fails because ZGC doesn't
> currently support that use case. In other words, the test shouldn't be
> test
Hi Per,
It looks good and trivial.
Thanks,
Serguei
On 9/26/19 1:39 PM, Per Liden wrote:
Please review this one-liner to disable
vmTestbase/nsk/jvmti/Allocate/alloc001 when using ZGC. The root
problem is that ZGC doesn't properly respect address space limitations
(RLIMIT_AS). This test will b
Hi Igor,
I don't think it belongs in the problem list, for two reasons:
1) The test doesn't fail because of a bug. It fails because ZGC doesn't
currently support that use case. In other words, the test shouldn't be
testing something that isn't supposed to work.
2) As far as I know, the test
Hi
Some hosts used for JDK testing have customized core dump settings. They
compress core files saved in current directory on-the-fly to reduce required
disk space.
This fix adopt several SA tests, trying to unpack core.pid.gz before test
process it with jhsdb. It affects only execution in the
Hi Per,
wouldn't it be better to put this test into zgc-specific problem list
(test/hotspot/jtreg/ProblemList-zgc.txt)?
Thanks,
-- Igor
> On Sep 26, 2019, at 1:39 PM, Per Liden wrote:
>
> Please review this one-liner to disable
> vmTestbase/nsk/jvmti/Allocate/alloc001 when using ZGC. The ro
Please review this one-liner to disable
vmTestbase/nsk/jvmti/Allocate/alloc001 when using ZGC. The root problem
is that ZGC doesn't properly respect address space limitations
(RLIMIT_AS). This test will be re-enabled again as part of fixing
https://bugs.openjdk.java.net/browse/JDK-8231552
Bug
Just figured you might want to know that the heap size change was
happening... :-)
Dan
On 9/26/19 2:06 PM, serguei.spit...@oracle.com wrote:
Dan, thank you for adding the serviceability-dev mailing list.
It looks good but has been already pushed. :)
Thanks,
Serguei
On 9/26/19 07:28, Daniel
Dan, thank you for adding the serviceability-dev mailing list.
It looks good but has been already pushed. :)
Thanks,
Serguei
On 9/26/19 07:28, Daniel D. Daugherty wrote:
Just for the record... JVM/TI belongs to the Serviceability Team
so I've added serviceability-dev@...
However, the Runtime
Thank you, Dan and Serguei.
Richard.
From: serguei.spit...@oracle.com
Sent: Donnerstag, 26. September 2019 16:33
To: daniel.daughe...@oracle.com; Reingruber, Richard
; Vladimir Kozlov ;
David Holmes ; hotspot-compiler-...@openjdk.java.net;
serviceability-dev@openjdk.java.net
Subject: Re: RFR(
I'm okay with that too.
Thanks,
Serguei
On 9/26/19 07:30, Daniel D. Daugherty wrote:
I'm
good with the testing that you've done. Thanks for closing the
loop.
Serguei?
Dan
On 9/26/19 3
I'm good with the testing that you've done. Thanks for closing the loop.
Serguei?
Dan
On 9/26/19 3:36 AM, Reingruber, Richard wrote:
Hi Dan and Serguei,
The change went through our nightly testing a few times, which
includes these tests and many more on all platforms.
Thanks, Richard.
*F
Just for the record... JVM/TI belongs to the Serviceability Team
so I've added serviceability-dev@...
However, the Runtime team and Serviceability team quite often tag
team on JVM/TI issues and lurk on each other's aliases...
Dan
On 9/26/19 3:14 AM, Per Liden wrote:
(CC:ing hotspot-runtime-de
Vladimir and Andrew, thanks for the feedback. Even if it is -1 so far ;)
I think I should clarify what my intend and motivation are.
Clearly it is not my intend to hinder optimization in the (potential) presence
of JVMTI agents. It
probably looks like it, though, as I'm opening all those bugs re
I think given the complexities involved in trying to make the JDI
connector's "thread-safe", i'm thinking now it's probably best leaving
this as-is. As Alan pointed out the java doc does not indicate it is meant
to be thread safe, and we will review the testcases that we have.
Thanks for all the
On 9/26/19 12:01 AM, dean.l...@oracle.com wrote:
On 9/25/19 6:21 PM, coleen.phillim...@oracle.com wrote:
I see. I dumped the redefinition count in the replay data because I
saw the other fields were dumped there. Would they also not affect
the generated code?
I know some like _jvmti_
On 9/26/19 5:43 AM, erik.osterl...@oracle.com wrote:
Hi Coleen,
Could you please make the counter uint64_t instead? We usually use 64
bit unsigned counters when we don't want to think about overflow.
Otherwise I like the approach. Don't need another webrev... This looks
good.
You are rig
On 9/26/19 4:47 AM, serguei.spit...@oracle.com wrote:
Hi Coleen,
The .02/webrev looks good.
You also removed changes in the
src/hotspot/share/jvmci/vmStructs_jvmci.cpp.
Was it intentional?
Yes, Gilles said that graal doesn't need the field.
Thanks for reviewing.
Coleen
Thanks,
Serguei
Hi Coleen,
Could you please make the counter uint64_t instead? We usually use 64
bit unsigned counters when we don't want to think about overflow.
Otherwise I like the approach. Don't need another webrev... This looks good.
Thanks,
/Erik
On 9/26/19 3:29 AM, coleen.phillim...@oracle.com wrote
Hi Coleen,
The .02/webrev looks good.
You also removed changes in the src/hotspot/share/jvmci/vmStructs_jvmci.cpp.
Was it intentional?
Thanks,
Serguei
On 9/25/19 18:29, coleen.phillim...@oracle.com wrote:
On 9/25/19 9:21 PM, coleen.phillim...@oracle.com wrote:
I see. I dumped the redefin
Hi Dan and Serguei,
The change went through our nightly testing a few times, which includes these
tests and many more on all platforms.
Thanks, Richard.
From: serguei.spit...@oracle.com
Sent: Mittwoch, 25. September 2019 19:10
To: daniel.daughe...@oracle.com; Reingruber, Richard
; Vladimir Ko
24 matches
Mail list logo
