On 28/05/2015 06:07, Mandy Chung wrote:
An update to this patch:
Updated patch looks good to me.
I assume that Alexander Kulyakhtin and others will follow up at some
point to also add @modules to aid test selection.
-Alan
On 28/05/2015 06:47, joe darcy wrote:
Hello,
The latest HotSpot integration into JDK 9 dev introduced a test
failure in
java/lang/invoke/8022701/MHIllegalAccess.java.MHIllegalAccess.java
Please review the change below to problem list the test until such
time as the fix for the test (JDK-808
Hello,
The latest HotSpot integration into JDK 9 dev introduced a test failure in
java/lang/invoke/8022701/MHIllegalAccess.java.MHIllegalAccess.java
Please review the change below to problem list the test until such time
as the fix for the test (JDK-8080428) propagates to dev:
--- a/test/Pro
Hello,
As the venerable URL
http://bugreport.sun.com/bugreport/
has been retired and replaced with
http://bugreport.java.com/bugreport/
Occurrences of the old URL in the source base should be updated. Please
review the patch below which does this:
--- a/src/java.base/share/native/li
Looks good to me, Mandy.
-Joe
On 5/27/2015 10:07 PM, Mandy Chung wrote:
An update to this patch:
Joe pointed out that javax/sql/testng has a TEST.properties file. I now move
the @modules from test/javax/sql/testng individual tests to the modules key in
TEST.properties.
$ hg diff test/javax
An update to this patch:
Joe pointed out that javax/sql/testng has a TEST.properties file. I now move
the @modules from test/javax/sql/testng individual tests to the modules key in
TEST.properties.
$ hg diff test/javax/sql/testng
diff --git a/test/javax/sql/testng/TEST.properties
b/test/javax
jtreg supports a new @modules to specify the module and the internal API that a
test depends on. This is to prepare when the module boundaries are enforced at
runtime. This initial patch is contributed by several of us including
Alexander Kulyakhtin and Alan.
Webrev at:
http://cr.openjdk.j
On 05/27/2015 01:10 PM, Xueming Shen wrote:
On 05/27/2015 12:43 PM, Ivan Gerasimov wrote:
On 27.05.2015 21:08, Xueming Shen wrote:
targLen = max(1, tagLen); ?
Well, almost :)
With such targLen, (i = j + targLen) would result in i == length() + 1, which
will cause IOOBE in the following a
On 05/27/2015 12:43 PM, Ivan Gerasimov wrote:
On 27.05.2015 21:08, Xueming Shen wrote:
targLen = max(1, tagLen); ?
Well, almost :)
With such targLen, (i = j + targLen) would result in i == length() + 1, which
will cause IOOBE in the following append().
I'm sure the algorithms can be adop
On 27.05.2015 21:08, Xueming Shen wrote:
targLen = max(1, tagLen); ?
Well, almost :)
With such targLen, (i = j + targLen) would result in i == length() + 1,
which will cause IOOBE in the following append().
I'm sure the algorithms can be adopted to run correctly with empty
target, it ju
+1
Naoto
On 5/27/15 12:09 PM, Roger Riggs wrote:
Please review this test modification to reduce the running time
and to apply the recommended randomness pattern.
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-random-8081022/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8081022
Hi,
Please help review the change of changing the hard-wired extended charsets
loading mechanism
to ServiceLoader.loadInstalled(), for the module system. With the fix for
JDK-8069588 in JDK 9 all
charsets needed to startup in supported environments are in the base module.
This change is to
use
Please review this test modification to reduce the running time
and to apply the recommended randomness pattern.
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-random-8081022/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8081022
Thanks, Roger
targLen = max(1, tagLen); ?
On 05/27/2015 10:59 AM, Ivan Gerasimov wrote:
On 27.05.2015 20:40, Xueming Shen wrote:
The .append(srepl) -> append(srep.value)
And I would simply remove the "fastpath" for the target.length() = 0 special
case ...
And maybe pick an appropriate initial size (ma
On 27.05.2015 20:40, Xueming Shen wrote:
The .append(srepl) -> append(srep.value)
And I would simply remove the "fastpath" for the target.length() = 0
special case ...
And maybe pick an appropriate initial size (maybe this.length + 16 *
diff) for the sb
to further reduce its internal expan
The .append(srepl) -> append(srep.value)
And I would simply remove the "fastpath" for the target.length() = 0 special
case ...
And maybe pick an appropriate initial size (maybe this.length + 16 * diff) for
the sb
to further reduce its internal expanding ...
Personally this code is straightfor
On 27.05.2015 18:44, Xueming Shen wrote:
You might want to use directly sb.append.(char[], off, len), instead
of append(str, off, len)/append(str).
Ah, yes sure! It would improve things.
I updated the webrev in place:
http://cr.openjdk.java.net/~igerasim/8058779/03/webrev/
However the genera
Have you tried to reduce iteration granularity?
Probably, checking execution duration on every test case is more robust.
Best regards,
Vladimir Ivanov
On 5/27/15 5:50 PM, Konstantin Shefov wrote:
Hello,
Please review the test bug fix
https://bugs.openjdk.java.net/browse/JDK-8062904
Webrev is
Evil header file io_util.h effectively requires its callers to include
fcntl.h first (on platforms where fcntl.h defines O_SYNC and D_SYNC) and
that is a BIG NONO. I would try hard to fix io_util.h now (instead of
adding workarounds to callers) and further, if any of its callers were
including fcn
On 5/27/15 8:27 AM, Alan Bateman wrote:
On 26/05/2015 20:23, Xueming Shen wrote:
Hi,
Please help review the changes for JDK-8028480 and JDK-8034773
issues:
https://bugs.openjdk.java.net/browse/JDK-8028480
https://bugs.openjdk.java.net/browse/JDK-8034773
webrev:
http://cr.openjdk.java.net/~she
You might want to use directly sb.append.(char[], off, len), instead of
append(str, off, len)/append(str).
Btw, is the target.lenght==0 the popular use case/scenario? Just wonder
why do we need a special case
here for it.
thanks,
-Sherman
On 5/27/15 8:29 AM, Ivan Gerasimov wrote:
For complete
For completeness, here's another webrev, which uses StringBuilder:
http://cr.openjdk.java.net/~igerasim/8058779/03/webrev/
Its performance is somewhere in between the current implementation and
the array-based implementation:
MyBenchmark.test thrpt 40 796'059.192 ± 12455.970 ops/s
Memory
Hi all,
The way the conversion between a lambda (or a method reference) and a
functional interface is specified doesn't take wildcard (exactly ?
super) into account making the concept of contravariance of functional
interface less intuitive that it should be.
The following code compiles:
p
On 26/05/2015 20:23, Xueming Shen wrote:
Hi,
Please help review the changes for JDK-8028480 and JDK-8034773
issues:
https://bugs.openjdk.java.net/browse/JDK-8028480
https://bugs.openjdk.java.net/browse/JDK-8034773
webrev:
http://cr.openjdk.java.net/~sherman/8028480_8034773/
This looks okay but
Hello,
Please review the test bug fix
https://bugs.openjdk.java.net/browse/JDK-8062904
Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/
Test fails only against JDK 8u and passes against JDK 9.
Thanks
-Konstantin
Thanks.
Your methods like ofArrayList declare that they
throw ReflectiveOperationException, but also have a try/catch to prevent
that from ever happening.
The assertions e.g.
OptimalCapacity.ofArrayList(XClass.class, "theList", N)
could look more like assertions, e.g.
OptimalCapacity.assertOptima
Thank you Peter for looking at this!
On 27.05.2015 16:15, Peter Levart wrote:
Hi Ivan,
How does this implementation compare to your's two regarding speed:
http://cr.openjdk.java.net/~plevart/jdk9-dev/String.replace/webrev.01/
You need to check for possible overflow here:
2287 re
On 27/05/2015 07:00, Mandy Chung wrote:
We discussed this offline and revised the proposal to group javap and classfile
library together with jdeps in jdk.jdeps module for static analysis tools to
live. The jdk.compiler module will contain the compiler and a couple of small
tools. Moving o
Hi Martin,
Untangling the past a bit. Perhaps this code could be cleaner but
priority-wise,
I've got some other things to do first.
The Windows fcntl.h does not define O_SYNC/O_DSYNC so its relative
include order is not significant.
The explicit define of O_SYNC and O_DSYNC make the API to t
Looks good to me.
/Erik
On 2015-05-27 15:40, Mandy Chung wrote:
It’s in my repo but missing from the webrev.
diff --git a/make/launcher/Launcher-jdk.jdeps.gmk
b/make/launcher/Launcher-jdk.jdeps.gmk
new file mode 100644
--- /dev/null
+++ b/make/launcher/Launcher-jdk.jdeps.gmk
@@ -0,0 +1,36 @@
It’s in my repo but missing from the webrev.
diff --git a/make/launcher/Launcher-jdk.jdeps.gmk
b/make/launcher/Launcher-jdk.jdeps.gmk
new file mode 100644
--- /dev/null
+++ b/make/launcher/Launcher-jdk.jdeps.gmk
@@ -0,0 +1,36 @@
+#
+# Copyright (c) 2015, Oracle and/or its affiliates. All rights r
> On May 27, 2015, at 12:34 AM, Peter Levart wrote:
>
> Hi Dmitry,
>
> The jdk part looks OK (no great changes on this side from last webrev). Is
> there a particular reason why the return type of printFinalizayionQueue()
> method is Object[] and not Map.Entry[] ?
>
Taking it further - is i
Hi Ivan,
How does this implementation compare to your's two regarding speed:
http://cr.openjdk.java.net/~plevart/jdk9-dev/String.replace/webrev.01/
It is not much shorter than your's first, but more object oriented ;-)
Regards, Peter
On 05/27/2015 11:36 AM, Ivan Gerasimov wrote:
Hi Sherman!
On 05/27/2015 11:36 AM, Ivan Gerasimov wrote:
Hi Sherman!
Please take a look at my other webrev, that I provided in the first
message.
WEBREV: http://cr.openjdk.java.net/~igerasim/8058779/01/webrev/
I used StringJoiner there, which in some aspects seems to fit better
here, comparing to Str
Hi Sherman!
Please take a look at my other webrev, that I provided in the first message.
WEBREV: http://cr.openjdk.java.net/~igerasim/8058779/01/webrev/
I used StringJoiner there, which in some aspects seems to fit better
here, comparing to StringBuilder.
It does reduce the code, but of course
Hello Mandy,
I don't see a Launcher-jdk.jdeps.gmk. Should there be one?
/Erik
On 2015-05-27 08:00, Mandy Chung wrote:
We discussed this offline and revised the proposal to group javap and classfile
library together with jdeps in jdk.jdeps module for static analysis tools to
live. The jdk.co
Hi Dmitry,
The jdk part looks OK (no great changes on this side from last webrev).
Is there a particular reason why the return type of
printFinalizayionQueue() method is Object[] and not Map.Entryint[]>[] ?
For the hotspot part, I have a few reservations. You expect that the
type of array el
On 27/05/2015 07:50, Martin Buchholz wrote:
Not really a review ... but ... if this is really catching a hotspot bug, I
would be tempted to leave the test failing to make it more likely that the
hotspot bug fix is not swept under the rug and forgotten.
I would agree except that there is a repro
On Tue, May 26, 2015 at 7:52 PM, Roger Riggs wrote:
> Hi,
>
> Sadly, but not entirely unexpectedly there is an anomaly in the include
> files:
> It seems that Windows does not define O_SYNC and O_DSYNC.
> To make up for the absence
> jdk/src/java.base/share/native/libjava/io_util.h
> conditional
39 matches
Mail list logo
