Hi Daniil,
It looks good.
Thanks,
Serguei
On 7/13/18 16:34, Daniil Titov wrote:
Please review the change that filters out 8 JDI and JDWP tests when running
with Graal. These tests consume all memory ( to force GC or to test that the
OutOfMemory error is thrown ) that sporadically results in
Looks good.
Chris
On 7/13/18 4:34 PM, Daniil Titov wrote:
Please review the change that filters out 8 JDI and JDWP tests when running
with Graal. These tests consume all memory ( to force GC or to test that the
OutOfMemory error is thrown ) that sporadically results in the exceptions in
the
Please review the change that filters out 8 JDI and JDWP tests when running
with Graal. These tests consume all memory ( to force GC or to test that the
OutOfMemory error is thrown ) that sporadically results in the exceptions in
the Graal compiler threads and failure.
Issue: https://bugs.open
Hi Gary,
I wasn't suggesting a shorter waittime to speed up the tests. It's just
another (of many) timeout related parameters use to detect (what should
be very uncommon) timeout failures sooner. I guess in that case it does
make the test faster in cases where it does timeout.
So one questio
We know that the default jtreg timeout is 2 minutes and typically
runs with a timeoutfactor of 4 or 10. So the harness "safety net"
is 8 to 20 minutes from jtreg.
It does appear that most of the vmTestbase tests use a 5 minute
waittime. I have seen waittime used in different ways. The one we
saw
Markus,
I filed the following bug for you:
JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker
for self thread
https://bugs.openjdk.java.net/browse/JDK-8207266
Dan
On 7/13/18 4:46 PM, Daniel D. Daugherty wrote:
On 7/13/18 2:44 PM, Daniel D. Daugherty wrote:
On 7/13/
On 7/13/18 2:44 PM, Daniel D. Daugherty wrote:
On 7/13/18 12:35 PM, Markus Gaisbauer wrote:
Hello,
I am trying to use ThreadMXBean::getThreadAllocatedBytes
(com.sun.management) to get the amount of allocated memory of the
current thread in some performance critical code.
Unfortunately, the
Hi Gary,
It looks like you have properly added timeout=300 wherever we use
-waittime:5. However, I'm not 100% convinced this is always the right
approach. In the bug description you said that -waittime is used as a
timeout for individual operations. However, there could be multiple of
those o
On 7/13/18 12:35 PM, Markus Gaisbauer wrote:
Hello,
I am trying to use ThreadMXBean::getThreadAllocatedBytes
(com.sun.management) to get the amount of allocated memory of the
current thread in some performance critical code.
Unfortunately, the current implementation can be rather slow and th
Here's the starting point for openjdk contributing:
http://openjdk.java.net/contribute/
Here's your post in the mail archives :
http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-July/024441.html
Most people will post a webrev to cr.openjdk.java.net for larger changesets.
Most
Hello,
I am trying to use ThreadMXBean::getThreadAllocatedBytes
(com.sun.management) to get the amount of allocated memory of the current
thread in some performance critical code.
Unfortunately, the current implementation can be rather slow and the
duration of each call unpredictable. I ran a tes
Hi Gary,
It looks good.
Thanks,
Serguei
On 7/13/18 04:29, Gary Adams wrote:
This is a simple update to set the jtreg timeout to match the
internal waittime already being used by these vmTestbase/nsk/jdb tests.
Issue: https://bugs.openjdk.java.net/browse/JDK-8206013
Webrev: http://cr.open
Great! Thanks Erik.
Mandy
On 7/13/18 1:34 AM, Erik Helin wrote:
On 07/12/2018 10:34 PM, mandy chung wrote:
It's indeed strange that no one reports this issue. I created:
https://bugs.openjdk.java.net/browse/JDK-8207200
Mandy: I moved the bug over to hotspot/gc, this is much more likely
Hi,
I have good news. I was able to reproduce this issue but this time I
have logs. A test failed with the following stack trace around
15:06:55 with:
java.lang.IllegalArgumentException: committed = 537919488 should be <
max = 536870912
>at java.lang.management.MemoryUsage.(MemoryUsage.jav
Hi Serguei,
Sorry for the late reply, but it seems the spam filter has removed your emails.
I just saw them in the archives.
Regarding this code:
288 if (length != count) {
289 error = JVMTI_ERROR_INTERNAL;
290 }
count is the number of frames filled into the array (it is set
This is a simple update to set the jtreg timeout to match the
internal waittime already being used by these vmTestbase/nsk/jdb tests.
Issue: https://bugs.openjdk.java.net/browse/JDK-8206013
Webrev: http://cr.openjdk.java.net/~gadams/8206013/webrev.00/
On 07/12/2018 10:34 PM, mandy chung wrote:
It's indeed strange that no one reports this issue. I created:
https://bugs.openjdk.java.net/browse/JDK-8207200
Mandy: I moved the bug over to hotspot/gc, this is much more likely to
be a problem with how the GC calculates the sizes. I don't thin
On Fri, 2018-07-13 at 10:30 +0200, Daniel Mitterdorfer wrote:
> Hi Erik,
> >
> > Do you any kind of GC logging from the test run where you
> > encountered the bug?
>
> Unfortunately, we don't have GC logging enabled by default in our
> test suite so the exception trace is all I got. I am now repe
Hi Erik,
>
> Do you any kind of GC logging from the test run where you encountered
> the bug?
Unfortunately, we don't have GC logging enabled by default in our test
suite so the exception trace is all I got. I am now repeatedly running
the test suite with the original flags (-Xms512M -Xmx512M) and
Hi Alan,
understood. Thanks for clarifying.
Daniel
Am Fr., 13. Juli 2018 um 10:15 Uhr schrieb Alan Bateman
:
>
>
>
> On 13/07/2018 09:04, Daniel Mitterdorfer wrote:
> > Hi Mandy,
> >
> > thank you for creating the issue. One note: I spotted this in JDK 10
> > (build 10.0.1+10) but in the ticket i
Hi Daniel,
thanks for letting us know. Since you have only set -Xms512 and -Xmx512
and you are running on JDK 10 that means you are using the G1 garbage
collector, so all the calls to pool->get_memory_usage() in the loop will
end up in g1MemoryPool.cpp [0] which in turn will return cached valu
On 13/07/2018 09:04, Daniel Mitterdorfer wrote:
Hi Mandy,
thank you for creating the issue. One note: I spotted this in JDK 10
(build 10.0.1+10) but in the ticket it says it affects version 8.
A bug with affects version N is assumed to be applicable to all releases
> N unless tagged otherwi
Hi Mandy,
thank you for creating the issue. One note: I spotted this in JDK 10
(build 10.0.1+10) but in the ticket it says it affects version 8.
Daniel
Am Fr., 13. Juli 2018 um 04:15 Uhr schrieb mandy chung :
>
> It's indeed strange that no one reports this issue. I created:
> https://bugs.o
23 matches
Mail list logo
