Hi David,
tag added because tests contain string
cmd.addAll(JpsHelper.getVmArgs());
and JpsHelper defines
...
public static final String[] VM_ARGS = {-Xmx512m, -XX:+UseParallelGC};
...
public static ListString getVmArgs() throws IOException {
if (testVmArgs == null) {
Hi,
After further off list discussion it was decided to keep the gc_tracer
in par_promote as is.
I have uploaded a new webrev,
http://cr.openjdk.java.net/~sfriberg/8055845/webrev.05
The main change here is a rewrite of the G1 code which is cleaner and
also reuses the read age. By sending
On 6/11/2014 8:05 PM, Evgeniya Stepanova wrote:
Hi David,
tag added because tests contain string
cmd.addAll(JpsHelper.getVmArgs());
and JpsHelper defines
...
public static final String[] VM_ARGS = {-Xmx512m, -XX:+UseParallelGC};
Ah I see! Strange.
Thanks for clarifying.
Looks okay then.
Hi Evgeniya,
As David has pointed out these jps tests are not testing gc. The
-XX:+UseParallelGC is just an arbitrary chosen test flag. There should
not be any conflicts either since these tests are running in driver mode:
...
* @run driver TestJpsJar
...
which means no flags from above
If it's confusing the tests are using -XX:+UseParallelGC we can change
them to use some other neutral flag.
Plus there is no any sense to run test twice in TC (with different GC,
since it use only Parallel)
I agree it's meaningless to run them with all possible GC combinations
because these
Hi Staffan,
On 2014-11-06 11:12, Staffan Friberg wrote:
Hi,
After further off list discussion it was decided to keep the gc_tracer
in par_promote as is.
I have uploaded a new webrev,
http://cr.openjdk.java.net/~sfriberg/8055845/webrev.05
The main change here is a rewrite of the G1 code
Hi Katja,
You are right, there will be no conflict, because test ignores any
external VM flags.
So, adding @requires seems unnecessary here, but...
Ignoring external options is bad thing, such selfish tests are not
applicable for other areas, like GC, compiler, RT.
@requires will allow to
Good catch, fixed.
// Too large; allocate the object individually.
obj = sp-par_allocate(word_sz);
if (obj != NULL) {
gc_tracer()-report_promotion_outside_plab_event(old, word_sz,
age, false);
}
Please let me know if anyone wants a full new webrev with this.
On 2014-11-06 14:00, Staffan Friberg wrote:
Good catch, fixed.
// Too large; allocate the object individually.
obj = sp-par_allocate(word_sz);
if (obj != NULL) {
gc_tracer()-report_promotion_outside_plab_event(old, word_sz,
age, false);
}
Please let me know
Thanks a lot!
On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote:
Hi Katja,
Ok, this seems to be a perfect solution. Thank you. I'll change the
diff accordingly.
Thanks,
Evgeniya Stepanova
On 06.11.2014 16:56, Yekaterina Kantserova wrote:
Hi Dima,
On 11/06/2014 11:22 AM, Dmitry Fazunenko
David, you didn't recommend taking the code out, because it looked like
something that would trick people, so we'll leave it in. It's benign.
The rest of the change improves performance, which we want.
Thanks,
Coleen
On 11/6/14, 12:35 AM, David Holmes wrote:
Right - now I get it. Pointer
New webrev:
http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/
Thanks,
Evgeniya Stepanova
On 06.11.2014 17:35, Yekaterina Kantserova wrote:
Thanks a lot!
On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote:
Hi Katja,
Ok, this seems to be a perfect solution. Thank you. I'll change the
diff
Hi Evgeniya,
it seems like there is no need to use Serial GC in
java/lang/ref/EnqueuePollRace.java [1],
so it does make sense to remove that option instead of adding the @requires tag.
Thanks,
Filipp.
[1] https://bugs.openjdk.java.net/browse/JDK-8051723
On 11/06/2014 06:36 PM, Evgeniya
Hi reviewers,
I'm suggesting to review a modified fix:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.4/
The 3-rd round fix is not right as it caused deadlocks in several tests
(in nsk.jdi.testlist and jtreg com/sun/jdi).
Here is a deadlock example:
I forgot to tell that all the nsk.jdi.testlist, nsk.jdwp.testlist and
gtreg com/sun/jdi
tests successfully passed with the new fix.
No deadlocks are observed.
Thanks,
Serguei
On 11/6/14 2:27 PM, serguei.spit...@oracle.com wrote:
Hi reviewers,
I'm suggesting to review a modified fix:
Hi Serguei,
I think I get the gist of this approach but I'm not an expert on the JVM
TI or JDWP event model. My main concern would be how the delay to the
completion of cbVMDeath() might impact things - specifically if it might
be a lengthy delay?
Thanks,
David
On 7/11/2014 8:27 AM,
On 7/11/2014 12:36 AM, Evgeniya Stepanova wrote:
New webrev:
http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/
In:
test/java/lang/management/RuntimeMXBean/TestInputArgument.sh
the use of the gc options seems incidental - it's just picking two
innocuous options to use - similar to the
Hi David!
Ok, I'll change the diff.
Thank you
On 07.11.2014 9:37, David Holmes wrote:
On 7/11/2014 12:36 AM, Evgeniya Stepanova wrote:
New webrev:
http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/
In:
test/java/lang/management/RuntimeMXBean/TestInputArgument.sh
the use of the gc
18 matches
Mail list logo
