For what it's worth Daniil,
Webrev.02 LGTM :-)
I do believe at some point we go seem to go back and forth about JVMCI
testing and what we should do or not. I understand it should be a case by
case in a lot of spots but perhaps we should document somewhere our stance
for JVMCI test-bugs? Just
Thank you, Chris!
Please review a new version of the change that makes the test ignored if Graal
is enabled.
Webrev: http://cr.openjdk.java.net/~dtitov/8217827/webrev.02/
Bug: https://bugs.openjdk.java.net/browse/JDK-8217827
Best regards,
Daniil
On 3/22/19, 7:59 PM, "Chris Plummer"
Ok. No need to write the stress test now, just file the CR.
thanks,
Chris
On 3/22/19 4:07 PM, gary.ad...@oracle.com wrote:
Yes, there will be more follow up after the patch is pushed.
I started a thread on jtreg-dev to discuss the current implementation
and possibly an enhancement to meet
Hi Daniil,
So 8mb is enough to do at least 10,000 iterations and trigger JVMCI
initialization, but the amount of memory needed after the System.gc() is
more than the memory used by the loop (and then freed)? I wonder if more
compilation is being triggered after the System.gc() call, and that
Ok. The fix looks good to me.
thanks,
Chris
On 3/22/19 4:01 PM,
gary.ad...@oracle.com wrote:
Yes. I just made it clearer.
On 3/22/19 3:29 PM, Chris Plummer wrote:
Yes, there will be more follow up after the patch is pushed.
I started a thread on jtreg-dev to discuss the current implementation
and possibly an enhancement to meet the need of the vmTestbase
tests that may have the wrong expectation of the current feature.
e.g. the previous test harness had a
Yes. I just made it clearer.
On 3/22/19 3:29 PM, Chris Plummer wrote:
Hi Gary,
It looks like there was already "-" support for the CCS column. Was it
not working, or did you add the parens just to make it clearer to the
reader what it is matching on?
thanks,
Chris
On 3/22/19 1:18 AM,
Hi Chris,
Addind -XX:+PrintCompilation flag shows that the first compiled method is
java.lang.Object::.
Max heap size and parameter for the warmup stage (10K iterations) were found a
posteriori, to ensure that JVMCI initialization is kicked but without throwing
OutOfMemoryError.
The heap
Hi Daniil,
What triggers the JVMCI initialization, what (in general) is done during
the initialization, and how did you come up with the 10k iterations and
a 10s sleep to ensure that initialization is complete?
What was the reason for the heap size increase? Does the OOME happen
before 10k
Please review the change that fixes the failure of the test when running with
Graal.
The problem here is that the test consumes all memory before JVMCI runtime is
fully initialized. As a result the call to
JVMCIRuntime::get_HotSpotJVMCIRuntime(CHECK_EXIT)
at
Hi Egor,
It looks Okay to me.
Just want to make sure all important JDI tests are run.
There are two major JDI test suites:
jdk/com/sun/jdi and hotspot/jtreg/vmTestbase/nsk/jdi
Thanks,
Serguei
On 3/22/19
Hi Gary,
The changes look fine, but are you going to file the CRs I suggested
(one for jtreg exclusiveAccess.dirs help text and one to further look
into this issue)?
thanks,
Chris
On 3/22/19 1:38 AM, gary.ad...@oracle.com wrote:
This proposed change will configure the sun/tools/j* and
Hi Gary,
It looks like there was already "-" support for the CCS column.
Was it not working, or did you add the parens just to make it
clearer to the reader what it is matching on?
thanks,
Chris
On 3/22/19 1:18 AM,
Thanks for your comments,
some jdi test were really failing :(
As we switched from TreeSet to HashSet we have to explicitly set
signature now.
Please review the updated fix:
http://cr.openjdk.java.net/~eushakov/8146986/webrev.01/
On 21-Mar-19 22:39, Jean Christophe Beyler wrote:
Hi Egor,
Is there ever a situation where the memory.limit_in_bytes could be unlimited
but the
hierarchical_memory_limit is not?
Could you maybe combine subsystem_file_contents with
subsystem_file_line_contents
by adding an additional argument?
BTW: I found another problem with the mountinfo/cgroup
Hi Gary,
Looks good to me though there's an itch to try to make the regex easier to
read/maintain :)
Jc
On Fri, Mar 22, 2019 at 1:18 AM gary.ad...@oracle.com
wrote:
> The M and CCS columns from jstat output can present a dash("-")
> for NaN values, such as :
>
>
Hi Gary,
Holding a static reference to the implementation solves the problem.
But I noticed that the object that is bound in the registry is the
RemoteHostImpl
and it should be the RemoteHost stub.
Line 145: should be:
bind(name.toString(), stub);
That is likely to solve the
Hi,
Please review this change which improves container detection support
tin the JVM. While docker container detection works quite well the
results for systemd slices with memory limits are mixed and depend on
the Linux kernel version in use. With newer kernel versions becoming
more widely used
This proposed change will configure the sun/tools/j* and
com/sun/tools/attach tests to be labeled as jtreg exclusiveAccess.dirs
so the java attaching tests are not run concurrently.
There is only annecdotal observations that multiple
tools are running when these tests are timing out.
1000s of
The M and CCS columns from jstat output can present a dash("-")
for NaN values, such as :
--System.out:(13/1261)--
S0 S1 E O M CCSYGC YGCTFGCFGCTCGC
CGCT GCT
0.00 0.00 0.00 0.00 - - 00.000 0
Here's a proposed fix for the intermittent jstatd test failure.
By moving the exported object from a local method variable to a
static class variable a strong reference is held so the object
will not be garbage collected prematurely.
Webrev:
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/remove_l/remove_l004 failed due to "TIMEOUT
while waiting for event"
22 matches
Mail list logo
