On 16/09/2014 22:45, Paul Sandoz wrote:
Hi,
Please see below for a patch to disable concurrent execution of the stream
tests by jtreg.
Looks good to me too, we should know soon enough if it helps with the
timeout issues (just in case there is something else going on).
-Alan
Hello!
Is there any interest in this change?
It's mostly cleanup, so it is of low priority, but it would be good, if
someone could review this.
Besides increased readability, this fix makes the code 24 lines shorter
and eliminates a compiler warning! :-)
Sincerely yours,
Ivan
On
Hi Brian,
I hope there will be a backport to JDK8?
Regards,
Robert
On 15 Sep 2014, at 22:14, Brian Burkhalter brian.burkhal...@oracle.com
wrote:
Hi Joe,
This has been pushed http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b20d87c5905
with the indicated comment excised.
Thanks,
Brian
On 16/09/2014 16:31, Daniel Fuchs wrote:
Done.
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.06
Thanks for the updates, I think this looks good now.
-Alan
http://cr.openjdk.java.net/~vlivanov/8058626/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8058626
I've noticed a difference between 8057656 fixes in 8u-dev [1] and 9 [2].
It seems I integrated [3] into 8u and [4] into 9.
This change syncs 8u to 9.
Thanks!
Best regards,
Vladimir Ivanov
Hi everybody,
please review patch fixing following issue:
JBS: https://bugs.openjdk.java.net/browse/JDK-8038966
webrev:
http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
http://cr.openjdk.java.net/~mkos/8038966/jdk.01/
It is second part of fix ensuring that content of type
On Sep 17, 2014, at 1:09 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8058626/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8058626
I've noticed a difference between 8057656 fixes in 8u-dev [1] and 9 [2].
It seems I integrated [3] into
Thanks, Paul!
Best regards,
Vladimir Ivanov
On 9/17/14, 5:38 PM, Paul Sandoz wrote:
On Sep 17, 2014, at 1:09 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8058626/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8058626
I've noticed a
Miran,
the src change looks ok but I think there's a problem with the testcase.
You've defined generated classes for wsimport to be output to the TESTSRC
directory. This is often read only and won't work.
TESTCLASSES is the variable you're probably looking for. In any case, I
think
it's
http://cr.openjdk.java.net/~vlivanov/8058309/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8058309
j.l.i.LambdaForm class has ~50-100 dependent nmethods on average. For
every compiled LF, Unsafe.defineAnonymousClass() should validate all
dependencies on parent class. Since thousands of
On 09/17/2014 07:02 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8058309/webrev.00/
Looks good, thanks!
Sorry for not being clear earlier, but I am a bit concerned with the bug
synopsis: we have sure worked around the issue with LambdaForms, but are
we sure this fixed the
Looks good, but I would use this title:
(str) Improve String.hashCode implementation
On Wed, Sep 17, 2014 at 7:28 AM, Aleksey Shipilev
aleksey.shipi...@oracle.com wrote:
Hi,
Can I have a review and a sponsorship for this tiny readability cleanup
in String.hashCode()?
Hi Robert,
That’s the plan.
Regards,
Brian
On Sep 17, 2014, at 2:35 AM, Robbie Gibson robbiexgib...@yahoo.com wrote:
I hope there will be a backport to JDK8?
On 17/09/2014 15:28, Aleksey Shipilev wrote:
Hi,
Can I have a review and a sponsorship for this tiny readability cleanup
in String.hashCode()?
http://cr.openjdk.java.net/~shade/8058643/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8058643
Looks good to me.
-Alan
On 17/09/2014 16:29, Amy Lu wrote:
Hi, David
Thank you for your review!
Here's the updated version, run jar tool directly:
webrev: http://cr.openjdk.java.net/~tyan/amylu/8058569/webrev.02/
com.sun.tools.javac.Main is not reported as internal API so far (see
below jdeps result before the
It definitely helps the readability. String.hashCode() has intrinsics,
so I don't think
we are seeing the real performance difference of the implementations.
My guess
is the original one probably is faster.
On 9/17/14 8:25 AM, Aleksey Shipilev wrote:
Thanks Martin!
It used to be Clean-up
There's no such intrinsic; there's intrinsic support for calling native
object hashcode, but string isn't special cased.
Sent from my phone
On Sep 17, 2014 12:14 PM, Xueming Shen xueming.s...@oracle.com wrote:
It definitely helps the readability. String.hashCode() has intrinsics,
so I don't
You's right. The native implementation in vm is only for those
constants, and that's not intrinsic.
On 9/17/14 9:20 AM, Vitaly Davidovich wrote:
There's no such intrinsic; there's intrinsic support for calling
native object hashcode, but string isn't special cased.
Sent from my phone
On
Aleksey,
Sorry for not being clear earlier, but I am a bit concerned with the bug
synopsis: we have sure worked around the issue with LambdaForms, but are
we sure this fixed the general problem? John asked me to follow up on
that with more concrete benchmark, and I will do that later. In other
Hi Xueming,
On 09/17/2014 08:13 PM, Xueming Shen wrote:
String.hashCode() has intrinsics,
No, we have no intrinsics for String.hashCode. We do have a native
implementation for VM internal purposes though, but it's irrelevant here.
so I don't think we are seeing the real performance
On 09/17/2014 08:43 PM, Vladimir Ivanov wrote:
I don't see anything obviously wrong either with U.dAC() or with
dependency tracking in VM. What we stumbled upon is an inherent
limitation of current dependency tracking implementation.
Yes, and so the question from John, which I need to follow
You're correct. I was confused by the hash_code() in javaClass that I'm
recently working on:-)
that is for those constants only.
-Sherman
On 9/17/14 9:43 AM, Aleksey Shipilev wrote:
Hi Xueming,
On 09/17/2014 08:13 PM, Xueming Shen wrote:
String.hashCode() has intrinsics,
No, we have no
[image: Read zip files from the beginning? Read zip files from the end?
(both)]
On Tue, Sep 16, 2014 at 9:03 AM, Xueming Shen xueming.s...@oracle.com
wrote:
On 9/15/14 6:40 PM, Martin Buchholz wrote:
Hi Alan, Xueming,
I'd like you to do a code review.
It's not specific to U.dAC(). Regular class loaders can hit similar
problem as well.
Even better, this is even more generic.
Please, update bug synopsis then.
If you want to use 8058309 for dependency tracking improvments in VM,
let me know. So far, I got an impression it is about LFs
On 09/17/2014 08:55 PM, Vladimir Ivanov wrote:
It's not specific to U.dAC(). Regular class loaders can hit similar
problem as well.
Even better, this is even more generic.
Please, update bug synopsis then.
Thanks, did so. Also reassigned the bug, and lowered the priority.
Done:
Hello,
Issue: https://bugs.openjdk.java.net/browse/JDK-8058664
Webrev: http://cr.openjdk.java.net/~bpb/8058664/webrev.00/
Somehow some bad fonts got in to the line prefixes of some comments and none of
the tools caught it.
Thanks,
Brian
On 17/09/2014 18:43, Brian Burkhalter wrote:
Hello,
Issue: https://bugs.openjdk.java.net/browse/JDK-8058664
Webrev: http://cr.openjdk.java.net/~bpb/8058664/webrev.00/
Somehow some bad fonts got in to the line prefixes of some comments and none of
the tools caught it.
    Looks good :-)
On 9/17/2014 8:37 AM, Alan Bateman wrote:
On 17/09/2014 16:29, Amy Lu wrote:
Hi, David
Thank you for your review!
Here's the updated version, run jar tool directly:
webrev: http://cr.openjdk.java.net/~tyan/amylu/8058569/webrev.02/
com.sun.tools.javac.Main is not reported as internal API so
On 09/17/14 10:46, Alan Bateman wrote:
On 17/09/2014 18:43, Brian Burkhalter wrote:
Hello,
Issue:https://bugs.openjdk.java.net/browse/JDK-8058664
Webrev:http://cr.openjdk.java.net/~bpb/8058664/webrev.00/
Somehow some bad fonts got in to the line prefixes of some comments
and none of
On Tue, Sep 16, 2014 at 9:03 AM, Xueming Shen xueming.s...@oracle.com
wrote:
There is also some regressions reported later with the ZipFile path when
dealing with
some wrong/non-ZIP64-spec-compliant huge zip file, in which it's fine
to access those
entries from the beginning of the stream,
On 09/17/2014 06:55 PM, Vladimir Ivanov wrote:
It's not specific to U.dAC(). Regular class loaders can hit similar
problem as well.
Even better, this is even more generic.
Please, update bug synopsis then.
If you want to use 8058309 for dependency tracking improvments in VM,
let me know.
On 09/17/2014 10:53 PM, Remi Forax wrote:
On 09/17/2014 06:55 PM, Vladimir Ivanov wrote:
It's not specific to U.dAC(). Regular class loaders can hit similar
problem as well.
Even better, this is even more generic.
Please, update bug synopsis then.
If you want to use 8058309 for
Hello bad characters,
Issue: https://bugs.openjdk.java.net/browse/JDK-8058679
Webrev: http://cr.openjdk.java.net/~bpb/8058679/webrev.00/
Tested with -encoding US-ASCII” passed to javac.
Thanks,
Brian
On 17/09/2014 21:48, Brian Burkhalter wrote:
Hello bad characters,
Issue: https://bugs.openjdk.java.net/browse/JDK-8058679
Webrev: http://cr.openjdk.java.net/~bpb/8058679/webrev.00/
Tested with -encoding US-ASCII” passed to javac.
\ufffd\ufffd Looks okay and if it compiles with -encoding
On 18/09/2014 1:29 AM, Amy Lu wrote:
Hi, David
Thank you for your review!
Here's the updated version, run jar tool directly:
webrev: http://cr.openjdk.java.net/~tyan/amylu/8058569/webrev.02/
Looks fine to me.
Thanks,
David
com.sun.tools.javac.Main is not reported as internal API so far
On 9/18/14, 10:51 AM, David Holmes wrote:
On 18/09/2014 1:29 AM, Amy Lu wrote:
Hi, David
Thank you for your review!
Here's the updated version, run jar tool directly:
webrev: http://cr.openjdk.java.net/~tyan/amylu/8058569/webrev.02/
Looks fine to me.
Thank you David!
May I have your help
On 18/09/2014 12:59 PM, Amy Lu wrote:
On 9/18/14, 10:51 AM, David Holmes wrote:
On 18/09/2014 1:29 AM, Amy Lu wrote:
Hi, David
Thank you for your review!
Here's the updated version, run jar tool directly:
webrev: http://cr.openjdk.java.net/~tyan/amylu/8058569/webrev.02/
Looks fine to me.
37 matches
Mail list logo
