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.
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 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 (se
On Sep 17, 2014, at 1:52 PM, Alan Bateman wrote:
> 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”
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 US-
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 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 u
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 Tue, Sep 16, 2014 at 9:03 AM, Xueming Shen
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, but can't jump
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 t
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 f
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 :-)
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 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:
>> 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 & J
[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
wrote:
> On 9/15/14 6:40 PM, Martin Buchholz wrote:
>
>> Hi Alan, Xueming,
>>
>> I'd like you to do a code review.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8058520
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 intr
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
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 "differe
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
w
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
O
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" wrote:
>
> It definitely helps the "readability". String.hashCode() has intrinsics,
> so I don't think
> we are see
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-
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 fix),
Thanks Martin!
It used to be "Clean-up String.hashCode()", and Alan had improved it
since then. :) To Alan's defense, the bug report was shallow at that
point to understand what is being proposed. I changed the title to
"Improve...".
Cheers,
-Aleksey.
On 09/17/2014 07:19 PM, Martin Buchholz wrot
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 fix), if this changed in the future, it
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
Hi Robert,
That’s the plan.
Regards,
Brian
On Sep 17, 2014, at 2:35 AM, Robbie Gibson wrote:
> I hope there will be a backport to JDK8?
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()?
> http://cr.open
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 gen
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 LF
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
Thanks,
-Aleksey.
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 possi
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
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
On Sep 17, 2014, at 1:09 PM, Vladimir Ivanov
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 8u and [4] into 9.
> Th
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
xsd:any/content=mix
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
[
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
Hi Brian,
I hope there will be a backport to JDK8?
Regards,
Robert
> On 15 Sep 2014, at 22:14, Brian Burkhalter
> 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 Sep 13,
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 10.09.2014
40 matches
Mail list logo
