Re: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1

On 12/17/2015 02:34 AM, Ulf wrote: > I'm wondering why moving the increment operation to an extra line wound > enhance performance. Because C1 is very straightforward, and code movement like that is a poor man's instruction scheduling, that pads out the data dependency between index update and ind

Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

Hi Anirvan, j.u.z.CRC32 supports 8-bits value and byte array. update(int, int) which you suggested will calculate lower 8-bits value: http://docs.oracle.com/javase/8/docs/api/java/util/zip/CRC32.html#update-int - http://hg.openjdk.java.net/jdk9/dev/jdk/file/a204b8e18d46/src/java.base/share/clas

Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

(Not an OpenJDK reviewer) Hi, I was wondering if the CRC32 implementation in TraditionalZipCryption could be replaced with java.util.zip.CRC32 class. Though I note that in this case TraditionalZipCryption#updateKeys(int c) will require CRC32#update(int crc, int b) method which is currently marke

Re: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1

Hi, I'm wondering why moving the increment operation to an extra line wound enhance performance. To prevent others from redoing the change later, I think a comment is needed. -Ulf Am 16.12.2015 um 20:11 schrieb Aleksey Shipilev: Hi, I would like to suggest a simple cleanup/improvement in cu

Re: RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile

Hi, yes, since the fields are package-private, this seems OK. /Claes On 2015-12-16 23:53, Aleksey Shipilev wrote: Hi, Since the dawn of OpenJDK, AbstractMap.keySet and .value were defined as package-private volatile fields. Their only use is to cache keySet and valueSet implementations from j

RFR (XS) 8145539: (coll) AbstractMap.keySet and .values should not be volatile

Hi, Since the dawn of OpenJDK, AbstractMap.keySet and .value were defined as package-private volatile fields. Their only use is to cache keySet and valueSet implementations from java.util collections. However, all relevant java.util collections are not having any declared fields (an opaque refere

Re: RFR [9] Remove sun.misc.Queue and replace usages with standard Collections

What is the reason to use assertion? If the problem is not theoretical, That was tricky to spot :-) nearly missed it. Since the queue is not "capacity-restricted" i think add(E) is the more appropriate choice. +1 I think so. — I suspect this use of queues in AppletPanel could be cleaned u

Re: JDK 9 RFR to problem list a failing test

Unless there's a reason not to, sun.misc.BASE64Encoder can replaced with its equivalent java.util.Base64. Cheers, Paul On Wed, Dec 16, 2015 at 4:00 PM, Xueming Shen wrote: > + 1 > > > On 12/16/15, 1:58 PM, joe darcy wrote: > >> Hello, >> >> The test >> >> java/beans/Introspector/Test6277246.jav

Re: JDK 9 RFR to problem list a failing test

Hi, Joe. I think it is quite easy to fix the test itself. Just use some other existed class from sun.misc. On 17/12/15 00:58, joe darcy wrote: Hello, The test java/beans/Introspector/Test6277246.java fails to compile after the change for JDK-8144479 , reporting an error /scratch/jenkins/wo

Re: JDK 9 RFR to problem list a failing test

> On Dec 16, 2015, at 1:58 PM, joe darcy wrote: > > > diff -r 98d9eb6f737f test/ProblemList.txt > --- a/test/ProblemList.txtWed Dec 16 20:00:03 2015 +0100 > +++ b/test/ProblemList.txtWed Dec 16 13:56:58 2015 -0800 > @@ -126,6 +126,9 @@ > java/beans/Introspector/8132566/OverridePropertyI

Re: JDK 9 RFR to problem list a failing test

+ 1 On 12/16/15, 1:58 PM, joe darcy wrote: Hello, The test java/beans/Introspector/Test6277246.java fails to compile after the change for JDK-8144479 , reporting an error /scratch/jenkins/workspace/9-dev-tier3-linux-x64/jdk/test/java/beans/Introspector/Test6277246.java:39: error: cannot fin

JDK 9 RFR to problem list a failing test

Hello, The test java/beans/Introspector/Test6277246.java fails to compile after the change for JDK-8144479 , reporting an error /scratch/jenkins/workspace/9-dev-tier3-linux-x64/jdk/test/java/beans/Introspector/Test6277246.java:39: error: cannot find symbol import sun.misc.BASE64Encoder;

Re: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1

+1 On 12/16/15, 11:11 AM, Aleksey Shipilev wrote: Hi, I would like to suggest a simple cleanup/improvement in current StringUTF16, which somewhat closes the gap between C1 and C2 performance with Compact Strings: https://bugs.openjdk.java.net/browse/JDK-8145428 http://cr.openjdk.java.net/

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

> On Dec 16, 2015, at 12:42 PM, Roger Riggs wrote: > Nit: There is no return value and this @return is not needed. >> * @return does not return >> > right I’m seeing this in other places. You can take them out before you push (no new webrev needed). >> >> In the test: >> 228

Re: RFR: jsr166 jdk9 integration wave 2

One more point - In try-with-resources it's clear that the try body is the "main event" while the auto-generated calls to close are intended to be "cleanup", so it's natural that the try body exception wins. With whenComplete: - it's less obvious that the whenComplete action is unimportant - both C

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Mandy, On 12/16/2015 3:07 PM, Mandy Chung wrote: The change On Dec 16, 2015, at 11:47 AM, Roger Riggs wrote: Hi Peter, It was a bit more involved than I expected, mostly in the tests to make this change. Is this what you expected? (just the deltas, I'll merge the patches before pushin

Re: RFR: jsr166 jdk9 integration wave 2

I'm in agreement with Peter. I don't see "handle", but rather "exceptionally", as the analog of java "catch". I agree with both Doug and Peter that it would be nice to have whenComplete as the analog of finally, but as Peter points out, the exception from the finally block wins, and that strength

Review Request 8144553: java/lang/StackWalker/StackWalkTest.java and MultiThreadStackWalk.java fail with stack overflows

This is a test fix to reduce the stack depth to avoid StackOverFlow when running with -Xcomp on solaris sparc. Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8144553/webrev.00/index.html I verified the tests on solaris-sparcv9 machine with fastdebug VM -Xcomp -ea -esa. Mandy

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

The change > On Dec 16, 2015, at 11:47 AM, Roger Riggs wrote: > > Hi Peter, > > It was a bit more involved than I expected, mostly in the tests to make this > change. > > Is this what you expected? (just the deltas, I'll merge the patches before > pushing). > > http://cr.openjdk.java.net/~

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Peter, It was a bit more involved than I expected, mostly in the tests to make this change. Is this what you expected? (just the deltas, I'll merge the patches before pushing). http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696-no-clear/ Thanks, Roger On 12/15/2015 6:01 PM, P

Re: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type

Thanks, change has been pushed. cheers /Joel On Wed, 16 Dec 2015 at 18:53 joe darcy wrote: > Hi Joel, > > FYI, ccc request now approved; thanks, > > -Joe > > > On 12/16/2015 1:15 AM, Joel Borggrén-Franck wrote: > > Sounds good. > > I'll ping someone in my time zone to check the status of the cc

Re: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1

Good! /Claes On 2015-12-16 20:11, Aleksey Shipilev wrote: Hi, I would like to suggest a simple cleanup/improvement in current StringUTF16, which somewhat closes the gap between C1 and C2 performance with Compact Strings: https://bugs.openjdk.java.net/browse/JDK-8145428 http://cr.openjdk.

Re: Need help to understand TLS behavior

On Tue, Dec 15, 2015 at 9:40 PM, David Holmes wrote: > As a point fix a way to change the stack size of the process reaper thread > might suffice. But that is a band-aid. I can imagine bugs of the form "when > we run our Java code stand-alone it runs fine, but as soon as we embed the > JVM in our

RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1

Hi, I would like to suggest a simple cleanup/improvement in current StringUTF16, which somewhat closes the gap between C1 and C2 performance with Compact Strings: https://bugs.openjdk.java.net/browse/JDK-8145428 http://cr.openjdk.java.net/~shade/8145428/webrev.02/ It does improve the score on

Re: RFR 4823133: RandomAccessFile.length() is not thread-safe

Calling naked fstat without _FILE_OFFSET_BITS=64 is a bug. Don't you need to call fstat64 if it's available? +jlong +handleGetLength(FD fd) +{ +struct stat sb; +if (fstat(fd, &sb) == 0) { +return sb.st_size; +} else { +return -1; +} +} On Wed, Dec 16, 2015 at 5:02

Re: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem

On Tue, Dec 15, 2015 at 2:12 PM, Bernd Eckenfels wrote: > Hello, > > I always like it when access() is used instead of stat() magic. > > I noticed that the new ProgramExists in java_md_common.c does not > anymore reject directories (which are typically executable). Not sure > it this matters or is

Re: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type

Hi Joel, FYI, ccc request now approved; thanks, -Joe On 12/16/2015 1:15 AM, Joel Borggrén-Franck wrote: Sounds good. I'll ping someone in my time zone to check the status of the ccc and push once it is approved. Thanks for the review Cheers /Joel On mån 14 dec. 2015 at 20:45 joe darcy

Re: RFR: jsr166 jdk9 integration wave 2

Hi Doug, On 12/16/2015 03:09 PM, Doug Lea wrote: On 12/02/2015 07:51 PM, Martin Buchholz wrote: We're stuck. Peter wants to make Throwables cloneable, I want to reverse the order of throwables and add the past Throwable as a suppressed exception to the exception of a dependent action, and Doug

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

Looks good. Thanks. > On Dec 16, 2015, at 1:13 AM, Konstantin Shefov > wrote: > > Christian > > I have fixed the enum so it uses "ENUMENTRY(int)" format now and does linear > search. > http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.04/ > > -Konstantin > > On 12/15/2015 08:36 PM, Ch

Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

Hi Sergey, Thank you for your comment. I added that description in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.02/ Thanks, Yasumasa On 2015/12/16 22:19, Sergey Bylokhov wrote: Should the new methods describe how they will work in case of null params? On 16/12/15

Re: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition

The configure change looks good. Can't comment on the code changes. /Erik On 2015-12-16 14:50, Magnus Ihse Bursie wrote: There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. This patch is provided by Timo Kinnunen . I am sponsoring this patch.

Re: RFR: jsr166 jdk9 integration wave 2

On 12/02/2015 07:51 PM, Martin Buchholz wrote: We're stuck. Peter wants to make Throwables cloneable, I want to reverse the order of throwables and add the past Throwable as a suppressed exception to the exception of a dependent action, and Doug wants the current webrev behavior of adding the de

RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition

There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. This patch is provided by Timo Kinnunen . I am sponsoring this patch. The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well. I'm not qui

Re: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem

Hi Bernd, Hello, I always like it when access() is used instead of stat() magic. I noticed that the new ProgramExists in java_md_common.c does not anymore reject directories (which are typically executable). Not sure it this matters or is intentional, it is a change in semantic. Yes as the

Re: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem

On 12/16/2015 1:24 AM, Mikael Gerdin wrote: On 2015-12-16 09:24, Mikael Gerdin wrote: Hi Kumar, On 2015-12-15 16:54, Kumar Srinivasan wrote: Hello, Please review fix for: JDK-8115868 The webrev is here: http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/ Since I don't feel qualified to c

Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

Should the new methods describe how they will work in case of null params? On 16/12/15 16:04, Yasumasa Suenaga wrote: I adapted this enhancement after JDK-8145260: http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.01/ Could you review it? Thanks, Yasumasa On 2015/12/12 21:23, Yasu

Re: RFR 4823133: RandomAccessFile.length() is not thread-safe

Hi, Updated the webrev(http://cr.openjdk.java.net/~vtewari/4823133/webrev0.1/ ) as per Martin review comment removed the _FILE_OFFSET_BITS from source. Thanks, Vyom On Tuesday 15 December 2015 10:55 PM, Martin Buchholz wrote: _FILE

Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

I adapted this enhancement after JDK-8145260: http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.01/ Could you review it? Thanks, Yasumasa On 2015/12/12 21:23, Yasumasa Suenaga wrote: Hi Sherman, Our proposal is affected by JDK-8142508. We have to change ZipFile.java and and ZipFile

Re: General question: sun package -> jdk package?

On 15/12/15 18:56, Joel Borggrén-Franck wrote: Hi Chris, I'm somewhat surprised to see ReflectionFactory on that list. Can you share more details around its external use? ReflectionFactory.newConstructorForSerialization is used by several popular third party serialization, mocking, proxying, l

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

Christian I have fixed the enum so it uses "ENUMENTRY(int)" format now and does linear search. http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.04/ -Konstantin On 12/15/2015 08:36 PM, Christian Thalinger wrote: On Dec 14, 2015, at 11:11 PM, Konstantin Shefov mailto:konstantin.she...@

Re: Need help to understand TLS behavior

On 16/12/15 05:35, David Holmes wrote: > It's kind of interesting we've never hit this before. It's very > frustrating that we hit it on a thread that couldn't care less about > the TLS variables that have claimed space on its stack. I guess they > need a notion of "inheritable thread-locals" too.

Re: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem

On 2015-12-16 09:24, Mikael Gerdin wrote: Hi Kumar, On 2015-12-15 16:54, Kumar Srinivasan wrote: Hello, Please review fix for: JDK-8115868 The webrev is here: http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/ Since I don't feel qualified to comment on the actual code changes I don't cons

Re: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type

Sounds good. I'll ping someone in my time zone to check the status of the ccc and push once it is approved. Thanks for the review Cheers /Joel On mån 14 dec. 2015 at 20:45 joe darcy wrote: > Hi Joel, > > Revised ccc request finalized for current version of the spec; should be > approved in a d

Re: RFR 4823133: RandomAccessFile.length() is not thread-safe

Hi All, Please find the updated webrev(http://cr.openjdk.java.net/~vtewari/4823133/webrev0.1/ ). I incorporated the review comments by Roger Riggs. Thanks, Vyom On Tuesday 15 December 2015 10:01 PM, Roger Riggs wrote: Hi Yvom, Min

Re: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem

Hi Kumar, On 2015-12-15 16:54, Kumar Srinivasan wrote: Hello, Please review fix for: JDK-8115868 The webrev is here: http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/ Since I don't feel qualified to comment on the actual code changes I don't consider this a code review but I looked at th