Re: RFR 8223593 : Refactor code for reallocating storage

Thank you Pavel and Roger for reviewing! I apologize for reiterating this. After off-line discussion with Stuart Marks, the fix was modified once again. The modifications were mostly stylistic: The used terminology now reflects that we work with arrays (thus 'length', not 'size' or 'capacity')

RFR: JDK-8223803: j.l.c.MethodTypeDesc::insertParameterTypes​ doesn't control type of parameters

Please review fix for [1] at [2] and the related CSR at [3]. Method java.lang.constant.MethodTypeDesc::insertParameterTypes​ should control the type of parameters being inserted. In particular, no parameter can be a class descriptor of primitive type |void|. This fix is updating the spec of the

Re: RFR8220166 : Performance regression in deserialization

On 5/15/19 10:32 PM, Roger Riggs wrote: > Issue: >   https://bugs.openjdk.java.net/browse/JDK-8220166 > > Webrev: >   http://cr.openjdk.java.net/~rriggs/webrev-fix-8220166/index.html This looks good to me, Roger. I also marked issue to get it on our backporting interest queue. -Aleksey

RFR8220166 : Performance regression in deserialization

Please review a change in the synchronization during the creation of an ObjectInputStream. Currently, a synchronized block is used to initialize the streams filter is read the global serial filter which becomes a bottleneck under high concurrency.  Since the value only ever changes from null to

Re: RFR: JDK-8223726: j.l.c.MethodTypeDesc spec should contain precise assertions for one parameter's methods

Hi Vicente, Should  180  * @throws NullPointerException if any argument is {@code null}  181  */  182 static DirectMethodHandleDesc ofConstructor(ClassDesc owner,  183 ClassDesc... paramTypes) { be "any argument or its contents is {@

Re: [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru

Thanks, Deepak. Looks good. Naoto On 5/15/19 6:13 AM, Deepak Kejriwal wrote: Thanks Naoto for review, please find below updated version of webrev:- http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.02/ Regards, Deepak -Original Message- From: Naoto Sato Sent: Tuesday, May 14, 2019

RFR: JDK-8223726: j.l.c.MethodTypeDesc spec should contain precise assertions for one parameter's methods

Please review fix for [1] at [2], this is a simple fix that is just rewording the doc of a couple of methods at java.lang.constant.MethodTypeDesc, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8223726 [2] http://cr.openjdk.java.net/~vromero/8223726/webrev.00/

RE: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler

Hi David, Martin, thanks for looking into this. Generally I share your view on this. It's not nice at all. However, it's the only way I can see currently to get rid of the Errors in the Eclipse IDE. Maybe an idea would be to get this in but at the same time open a ticket to evaluate this code

RE: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for JDK-8213031

Hi Lance, thanks for the quick turnaround. I tried to address your findings. Please find the new webrev here: http://cr.openjdk.java.net/~clanger/webrevs/876.3/ > o FindEND() > • I know that endsub and comlen fields are not currently used by Zip FS but > given they are valid fields in the h

RE: [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru

Thanks Naoto for review, please find below updated version of webrev:- http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.02/ Regards, Deepak -Original Message- From: Naoto Sato Sent: Tuesday, May 14, 2019 10:17 PM To: Deepak Kejriwal ; Ramanand Patil ; i18n-...@openjdk.java.net; co

Re: RFR(s): 8223777: In posix_spawn mode, failing to exec() jspawnhelper does not result in an error

* Thomas Stüfe: > Since we deal with many libc variants, not only glibc, fixing > posix_spawn just in glibc may not be sufficient, at least not for a > long time. I think Solaris already has the required functionality, so it's not entirely glibc-specific. > But if you would fix glibc and give it

Re: RFR(s): 8223777: In posix_spawn mode, failing to exec() jspawnhelper does not result in an error

Hi all, I am currently busy with other things, and I'd like to wait for Rogers and Martins opinion on this. I think Florans idea is elegant, but as I said, this is an area where I want to be super careful. To recap Florians idea: Using the already existing fail pipe Martin added for jspawnhelper