Re: JDK-8036003: Add variable not to separate debug information.

I don't think this quite works as there are other variations not captured here. Rather than "zipped" it should just be "external". Whether the debuginfo files are zipped or not is then an additional build time option. Additionally we still have to be able to control the degree of stripping th

Re: JDK-8036003: Add variable not to separate debug information.

On 21/03/2014 6:14 PM, Magnus Ihse Bursie wrote: I don't think this quite works as there are other variations not captured here. Rather than "zipped" it should just be "external". Whether the debuginfo files are zipped or not is then an additional build time option. Additionally we still have t

Re: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64

You’re right but we’ve never received a report of any charset interop. issues. Probably such a scenario has never been encountered by customers. On 21 Mar 2014, at 05:54, Xueming Shen wrote: > Obj.java:#482 >It appears sun.misc.BASE64Decoder.decodeBuffer(String) uses String's > deprecated

Re: JDK-8036003: Add variable not to separate debug information.

David, In practice, we don't have to much to keep internally. There are no reason to copy out some of .debug_* sections but keep other ones. So we have a matrix: (a) Strip mode: 1. full 2. keep symbols 3. keep symbols and .debug_* (b) Copy mode: 1. Copy all to ext file 2. Copy none to ext f

Re: JDK-8036003: Add variable not to separate debug information.

On 21/03/2014 7:36 PM, Dmitry Samersoff wrote: David, In practice, we don't have to much to keep internally. There are no reason to copy out some of .debug_* sections but keep other ones. I'm not familiar with exactly what the different strip options do but the point is this is covered by th

Re: JDK-8036003: Add variable not to separate debug information.

David, My point was that we don't need in fine grained selection of elf sections on strip - three options are enough. > Why does full strip + copy-all + zip make no sense? It is exactly what > we do with embedded builds. (Naturally you have to copy before you > strip) Sorry! it should be: full s

Re: [9] Review request: new macro for conversion to jboolean

Hi Sergey, I didn't see any examples of the use case in this thread. The proposed name seems bulky and clumsy. In the snippet provided, it did not seem necessary to force the cast to jboolean. Both JNI_TRUE and JNI_FALSE are untyped constants. The macro would just as useful (if I understan

Re: [9] Review request: new macro for conversion to jboolean

On 3/21/14 7:10 PM, roger riggs wrote: The macro would just as useful (if I understand the cases) without the cast. How useful is a simple definition as: #define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE) then it would look ok to see these in sources: return IS_TRUE(obj); if (I

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

Chris, Thanks for the feedback. What do you think about the following: http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/ Best regards, Vladimir Ivanov On 3/19/14 5:18 AM, Christian Thalinger wrote: On Mar 18, 2014, at 2:35 PM, John Rose mailto:john.r.r...@oracle.com>> wrote: On Mar 1

RFR: 8034944: (process) Improve subprocess handling on Solaris

Hi folks, I'd like to push this change into JDK8 & 7. There is other work going on in 9 which will supersede this fix so there is likely no point in pushing to that release. This is backport of the threadpool specific changes from https://bugs.openjdk.java.net/browse/JDK-6944584 along with s

Re: RFR: 8034944: (process) Improve subprocess handling on Solaris

..just realised I had an out of date webrev up there, I've just updated in place in case anyone is looking at it. -Rob On 21/03/14 17:43, Rob McKenna wrote: Hi folks, I'd like to push this change into JDK8 & 7. There is other work going on in 9 which will supersede this fix so there is l

Re: RFR: 8034944: (process) Improve subprocess handling on Solaris

Just when I thought I beat you to it Martin. :) On 21/03/14 18:32, Martin Buchholz wrote: OK, latest webrev looks much smaller, and appears to have only a port of changes from my changes to Linux from a few years ago. (please confirm). If so, Looks Good To Me. Yup, everything that is in thi

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

On Mar 21, 2014, at 8:49 AM, Vladimir Ivanov wrote: > Thanks for the feedback. > > What do you think about the following: > http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/ That looks nice. Strong typing; who woulda' thunk it. :-) The uses of ".ordinal()" are the extra cost relative

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

On 03/21/2014 07:54 PM, John Rose wrote: On Mar 21, 2014, at 8:49 AM, Vladimir Ivanov mailto:vladimir.x.iva...@oracle.com>> wrote: Thanks for the feedback. What do you think about the following: http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/

JDK 9 RFR of 8038163: Build failure on Mac OS 10.9.2 (Mavericks) due to warning treated as error

Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8038163 Patch: http://cr.openjdk.java.net/~bpb/8038163/ My only question would be whether the changed line 291 should instead be this: return (major > 1 || (major == 1 && minor >= 2)) ? JNI_TRUE : JNI_FALSE; Th

Re: JDK 9 RFR of 8038163: Build failure on Mac OS 10.9.2 (Mavericks) due to warning treated as error

Looks good to me. The version with JNI_TRUE/JNI_FALSE is more correct, but I’m fine with either one. (note: this review request should have been sent to serviceability-dev). Thanks, /Staffan On 21 mar 2014, at 20:41, Brian Burkhalter wrote: > Please review at your convenience: > > Issue:

Re: JDK 9 RFR of 8038163: Build failure on Mac OS 10.9.2 (Mavericks) due to warning treated as error

On Mar 21, 2014, at 12:44 PM, Staffan Larsen wrote: > Looks good to me. Thanks. > The version with JNI_TRUE/JNI_FALSE is more correct, but I’m fine with either > one. Updated to this form: http://cr.openjdk.java.net/~bpb/8038163/webrev.01/ > (note: this review request should have been sen

Re: JDK 9 RFR of 8038163: Build failure on Mac OS 10.9.2 (Mavericks) due to warning treated as error

On 21/03/2014 19:50, Brian Burkhalter wrote: On Mar 21, 2014, at 12:44 PM, Staffan Larsen wrote: Looks good to me. Thanks. The version with JNI_TRUE/JNI_FALSE is more correct, but I’m fine with either one. Updated to this form: http://cr.openjdk.java.net/~bpb/8038163/webrev.01/ (note:

Re: RFR: 8034944: (process) Improve subprocess handling on Solaris

On 21/03/2014 17:43, Rob McKenna wrote: : In a nutshell a new process reaper thread was spawned for every Process created by the JDK. This fix runs these reaper threads in a thread pool to save on thread creation when creating a lot of new processes. http://cr.openjdk.java.net/~robm/8034944

Review request for 8038177 Eliminate unnecessary dependency to sun.security.action

This is the second patch to eliminate the dependencies to sun.security.action: https://bugs.openjdk.java.net/browse/JDK-8038177 Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8038177/webrev.00/ Mandy

Re: [9] Review request: new macro for conversion to jboolean

What if we just abandon adding an IS_TRUE / TO_JBOOLEAN macro for now. I would like to address adding (jboolean) casts to jni.h which I suspect would help with the static analysis issues encountered. For now just use the explicit ? JNI_TRUE : JNI_FALSE whenever a jboolean value is needed and we

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

John, thanks for the feedback. Updated webrev: http://cr.openjdk.java.net/~vlivanov/8037210/webrev.02 Also moved LambdaForm.testShortenSignature() into a stand-alone unit test. Best regards, Vladimir Ivanov On 3/21/14 10:54 PM, John Rose wrote: On Mar 21, 2014, at 8:49 AM, Vladimir Ivanov mai

Re: [9] Review request: new macro for conversion to jboolean

On 3/22/14 1:38 AM, Mike Duigou wrote: What if we just abandon adding an IS_TRUE / TO_JBOOLEAN macro for now. I would like to address adding (jboolean) casts to jni.h which I suspect would help with the static analysis issues encountered. The problem, which I try to solve occurs, when we try to

Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

On Mar 20, 2014, at 12:49 AM, Aleksey Shipilev wrote: > On 03/20/2014 11:06 AM, Peter Levart wrote: >> I was thinking about last night, for question: "Why is this >> double-checked non-volatile-then-volatile trick not any faster than pure >> volatile variant even on ARM platform where volatile r

Re: StringBuilder version of java.util.regex.Matcher.append*

let's add the StringBuilder method(s), if you can provide an updated version, I can run the rest (since it's to add new api, there is an internal CCC process need to go through). -Sherman On 3/21/14 5:18 PM, Jeremy Manson wrote: So, this is all a little opaque to me. How do we make the go/no-g

Re: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64

Good catch Sherman. Vinnie - what's your recommendation for this LDAP change having both encode/decode uses the platform default charset (rather than retaining the old interop issue)? It's an incompatible change and I'll file a CCC to track this. Mandy On 3/21/2014 2:23 AM, Vincent Ryan wr