May 2014 - core-libs-dev

Webrev for 8043342: StringBuffer/StringBuilder crypto changes.
by Bradford Wetmore 22 May '14

22 May '14

No additional code review necessary, this is just an FYI. For internal reasons (i.e. we have to sign our JCE jar files), we have separated the JCE portion for: 8041679: Replace uses of StringBuffer with StringBuilder within the JDK into: 8043342: Replace uses of StringBuffer with StringBuilder within crypto code It's the exact same code, but only the four JCE files are included here. http://cr.openjdk.java.net/~wetmore/8043342/webrev.00/ I am sponsoring this for Jamil, from an original fix [1] sponsored by Paul Sandoz from: Otávio Gonçalves de Santana Thanks, Brad [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-May/026820.html

1 0

RFR 8043772: Typos in Double/Int/LongSummaryStatistics.java
by Ivan Gerasimov 22 May '14

22 May '14

Hello! Some functions were renamed with the fix for JDK-8015318. A few of them kept their old names in the comments. Would you please review this trivial fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043772 WEBREV: http://cr.openjdk.java.net/~igerasim/8043772/0/webrev/ Sincerely yours, Ivan

3 2

RFR - 8042857: 14 stuck threads waiting for notification on LDAPRequest
by Rob McKenna 22 May '14

22 May '14

Hi folks, A simple fix to eliminate a possible infinite loop when an Ldap Connection cannot contact the server. http://cr.openjdk.java.net/~robm/8042857/webrev.01/ -Rob

2 1

RFR JDK-8042887: Remove serialver -show, this tool does not need a GUI
by Pavel Rappo 22 May '14

22 May '14

Hi everyone, could you please review my change for JDK-8042887? http://cr.openjdk.java.net/~alanb/8042887/webrev/ I also created following issues for appropriate docs/localization updates: https://bugs.openjdk.java.net/browse/JDK-8043613 https://bugs.openjdk.java.net/browse/JDK-8043620 Thanks -Pavel

3 4

RFR(S): 8043520: Serviceability tests using @library failing with java.lang.NoClassDefFoundError
by Yekaterina Kantserova 22 May '14

22 May '14

Staffan, Alan, could you please review the following fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8043520 Webrev: http://cr.openjdk.java.net/~ykantser/8043520/webrev.00/ I've missed somehow several tests in http://cr.openjdk.java.net/~ykantser/8034960/webrev.01/ which existed in http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/. Thanks, Katja

3 5

RFR: Faster ZipFile.getEntry()/entries()
by Xueming Shen 22 May '14

22 May '14

Hi, The change proposed here is to bring the zip entry handing code from the native level to the java level. This effectively solves the performance issues of ZipFile.getEntry and entries() that is caused by multiple jni invocation steps to generate one single ZipEntry (see ZipFile.getZipEntry()). A simple non-scientific benchmark test of simply iterating the ZipFile via the Enumeration from entries() on rt.jar/charsets.jar suggests a 50%+ speed boost. http://cr.openjdk.java.net/~sherman/zipfile_j/webrev Couple notes: (1) Ideally it might be desired to go further to bring all the native code of ZipFile to java level (which should help completely remove that mmap crash issue, have better file and memory management... ), but it is suggested that it might be better to limit the scope of the change at this late release circle. (2) JavaFile.read0() is the version that uses "getPrimitiveArrayCritical" to read file bits into the java array directly (instead of using a stack buffer and then copy into the java array), which appears to be 5% faster. But I can't make up my mind of which one would be better. Given (1) the trouble we had before in De/Infalter code (when the getPrimitiveArrayCritical is being heavily used), (2) FileInputStream uses the same "copy" approach, I'm staying with the "copy" appraoch, but option appreciated. (3) We will have to keep the native implementation (zip_util.c) for the vm directly access. Thanks! -Sherman

3 4

RFR: 8039210: Fix type error in DefaultResourceInjector
by Miroslav Kos 19 May '14

19 May '14

Hi, this is review request for: 8039210: Fix type error in DefaultResourceInjector JBS: https://bugs.openjdk.java.net/browse/JDK-8039210 WEBREV: http://cr.openjdk.java.net/~mkos/8039210/jaxws.00/ It is simple one-line fix; it's blocker for another issue. Thanks Miran

2 1

8037343 Ready for review
by Sandipan Razzaque 18 May '14

18 May '14

Hi all, Please find below the webrev for bug 8037343. http://www.sandipan.net/public/webrevs/8037343/webrev.00 Thanks in advance - Cheers, SR Sandipan Razzaque | www.sandipan.net

3 2

RFR: 8043278: Add initial unit tests for javax.sql.rowset.serial
by Lance Andersen 16 May '14

16 May '14

Hi all, Looking for a reviewer for initial pass at adding some tests for javax.sql.rowset.serial The webrev can be found at http://cr.openjdk.java.net/~lancea/8043278/webrev.00/ Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen(a)oracle.com

2 3

Re: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache
by Remi Forax 16 May '14

16 May '14

On 05/16/2014 01:56 PM, Tobias Hartmann wrote: > Hi, > > thanks to everyone for the feedback. > > Is it sufficient then to use synchronized (lambdaForms) { ... } in > setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)? > > Thanks, > Tobias no, it's not, The memory model doesn't guarantee that a normal read will see that another thread has changed the array item, the normal read may always see null. You need a synchronized block around the normal read. Rémi > >>>> >>>>>>>> I may be wrong but for me cachedLambdaForm() is used in a fast >>>>>>>> path. >>>>>>>> If it's not the case, I agree that a lock is enough. >>>>>>> I hold the opinion that we only need to synchronize writers and not >>>>>>> readers (MTF.setCachedLambdaForm() and not MTF.cachedLambdaForm()). >>>>>>> >>>>>>> Current usage pattern is the following: >>>>>>> MethodType type = ...; >>>>>>> LambdaForm lform = type.form().cachedLambdaForm(idx); >>>>>>> if (lform == NULL) { >>>>>>> // construct new LambaForm >>>>>>> lform = type.form().setCachedLambdaForm(idx, lform); >>>>>>> } >>>>>>> return lform; >>>>>>> >>>>>>> Cache is written only once, so it has only 2 states (null and >>>>>>> non-null >>>>>>> value) during it's lifecycle. >>>>>>> >>>>>>> The only stale value cachedLambdaForm() can see is null, but >>>>>>> then the >>>>>>> caller tries to initialize the cache and after acquiring the >>>>>>> lock in >>>>>>> setCachedLambdaForm() sees actual value. >>>>>>> >>>>>>> So, the worst thing can happen if readers aren't synchronized is >>>>>>> creation of unnecessary LF (which go dead right away) in rare >>>>>>> cases. >>>>>> Unless the cache is volatile this would be unsafe publication and >>>>>> the >>>>>> reader may see a non-null reference to the LF but the LF may not be >>>>>> properly initialized. >>>>> Good point. The cache is an array element. How does safe publication >>>>> of array element look like? Is accessing the element through volatile >>>>> reference to the array enough or additional synchronization actions >>>>> are needed? >>>>> >>>> I thought that since the only fields explicitly set when constructing >>>> a LambdaForm are final fields it should be safe to publish the form >>>> reference as an element in the array? >>>> >>>> Paul. >>>> >>> >>> that's my analysis too. >> >> Sorry didn't realize a LF only had final fields. >> >> David >> >>> Rémi >>> >

2 2