Clean up serviceability/sa/TestUniverse.java to remove the need for the
withZ/withoutZ option we currently pass in. This also changes the test
to only run with the selected GC instead of testing all GCs every time,
which should save us some cycles in testing.
Bug: https://bugs.openjdk.java.net
Ping.
Still passes tests and is necessary to unblock work to more aggressively
archive invariant heap graphs.
/Claes
On 2019-03-15 17:26, Claes Redestad wrote:
Hi,
I ran into a few additional test issues, one exposing a crash in jmap
-histo:live in a test that seems to have been problem liste
[Adding hotspot-runtime-dev]
On 2019-03-15 17:26, Claes Redestad wrote:
Hi,
I ran into a few additional test issues, one exposing a crash in jmap
-histo:live in a test that seems to have been problem listed when I
ran tests earlier.
Also filtering out archived-but-not-yet-loaded classes in
Kla
Agreed.
Unless a test is specifically testing the functionality of
VirtualMachine.list()
it should not be used for locating a pid, which is easily provided
from the ProcessBuilder after the process is started.
Reducing the environmental interference of scanning all running java
processes
is
Here's an updated webrev that includes the change to bind to the stub.
The jstatd tests continue to pass after this change.
Webrev: http://cr.openjdk.java.net/~gadams/8203026/webrev.01/
It would be good to have a second reviewer from the serviceability team.
Longer term it would be good to rep
On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote:
> Is there ever a situation where the memory.limit_in_bytes could be unlimited
> but the
> hierarchical_memory_limit is not?
Yes. This is the very bug. Under a systemd slice with newer kernels the
memory.limit_in_bytes file OpenJDK looks at h
Looks good.
StefanK
On 2019-03-25 10:59, Per Liden wrote:
Clean up serviceability/sa/TestUniverse.java to remove the need for the
withZ/withoutZ option we currently pass in. This also changes the test
to only run with the selected GC instead of testing all GCs every time,
which should save us
Thanks Stefan!
/Per
On 3/25/19 2:44 PM, Stefan Karlsson wrote:
Looks good.
StefanK
On 2019-03-25 10:59, Per Liden wrote:
Clean up serviceability/sa/TestUniverse.java to remove the need for
the withZ/withoutZ option we currently pass in. This also changes the
test to only run with the select
Looks Okat to me.
Thanks,
Serguei
On 3/22/19 00:11, Nick Gasson wrote:
On 22/03/2019 00:17, Daniel D. Daugherty wrote:
You can list both bug IDs in the same changeset like this:
8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR:
thread2 is not alive"
8220456: jdi/EventQueue/rem
Hi Gary,
It looks good to me.
Nit:
It is better to define as interface:
+private static RemoteHostImpl remoteHost;
=>
+private static RemoteHost remoteHost;
+private static RemoteVmImpl rvm;
=>
+private static Re
On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote:
> Could you maybe combine subsystem_file_contents with
> subsystem_file_line_contents
> by adding an additional argument?
Done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/05/webrev/
Thanks,
Severin
During testing I found that there is still good reasons to leave 003 and
004
tests on the ProblemList. I believe there is still work to be done to
ensure
JDK-7013634 and JDK-6606767 are covered.
This pass attempts to solve the primary issue in this bug which is
improper paths on the
test comma
On 2019-03-25 17:51, Jiangli Zhou wrote:
Hi Claes,
The updated change also matches with the state of shared klasses, so it
seems good to me.
Thanks!
Sorry for the delay.
No worries, I was on vacation last week. :-)
It's probably a good idea to add
an assert to make sure k->is_shared
Hi Gary,
In resexhausted004.java, the
indentation needs to be fixed. Also, what happens if one of the
caught exceptions is thrown? Does the test fail or pass? I'm not
sure what the default behavior is if you just return from main().
Otherwise
Hi Claes,
It looks good.
I've targeted the bug to 13.
Thanks,
Serguei
On 3/25/19 04:23, Claes Redestad wrote:
[Adding hotspot-runtime-dev]
On 2019-03-15 17:26, Claes Redestad wrote:
Hi,
I ran into a few additional test issues, one exposing a crash in jmap
-histo:live in a test that seems t
On 2019-03-25 23:10, serguei.spit...@oracle.com wrote:
Hi Claes,
It looks good.
I've targeted the bug to 13.
Thanks, Serguei!
/Claes
Hi David,
http://cr.openjdk.java.net/~iklam/jdk13/8217347-appcds-InstrumentationTest-timeout.v02/
Thanks for the explanation. I've reverted my previous changes and
instead modified how the hand-shake is done. There's no need to use
VirtualMachine.list() as the pid is passed as part of the hand
Hi Egor,
Pushed.
Thanks,
Serguei
On 3/23/19 22:41, Egor Ushakov wrote:
Yes, the latest fix passed these test.
Serguei, can you please sponsor the fix?
On 22-Mar-19 23:25, serguei.spit...@oracle.com wro
Gary
Just want to add that following code
68 } catch (OutOfMemoryError me) {
69 me.printStackTrace();
70 }
might throw another OOME in printStackTrace().
If you want to do something after OOME it is needed to free some before trying
to allocate.
Leonid
> On
printStackTrace shouldn't ever result
in an OOME since the memory held that caused the previous OOME
should be released before another OOME is generated (no longer any
references to it).
Chris
On 3/25/19 9:56 PM, Leonid Mesnik
On 26/03/2019 3:05 pm, Chris Plummer wrote:
printStackTrace shouldn't ever result in an OOME since the memory held
that caused the previous OOME should be released before another OOME is
generated (no longer any references to it).
It will depend on the code executed leading up to and after the
On 3/25/19 10:11 PM, David Holmes wrote:
On 26/03/2019 3:05 pm, Chris Plummer wrote:
printStackTrace shouldn't ever result in an OOME since the memory
held that caused the previous OOME should be released before another
OOME is generated (no longer any references to it).
It will depend on the
On 26/03/2019 3:34 pm, Chris Plummer wrote:
On 3/25/19 10:11 PM, David Holmes wrote:
On 26/03/2019 3:05 pm, Chris Plummer wrote:
printStackTrace shouldn't ever result in an OOME since the memory
held that caused the previous OOME should be released before another
OOME is generated (no longer a
23 matches
Mail list logo
