Re: [9] 8149571: [launcher] create a regression test to test symlinks on Windows

[Oleg G. Barbashov]

Hi,

Please review the simple test of launcher started using a symlink.

issue: https://bugs.openjdk.java.net/browse/JDK-8149571
webrev: http://cr.openjdk.java.net/~ogb/8149571/

Thanks,
Oleg

Re: RFR(s): 8153330: deprecate Runtime.traceInstructions & traceMethodCalls for removal

[Mandy Chung]

> On Apr 19, 2016, at 3:11 PM, Stuart Marks  wrote:
> 
> Hi all,
> 
> I missed a couple bits of cruft in the previous round of java.lang 
> deprecations: the Runtime.traceInstructions() and traceMethodCalls() methods.
> 
> Their implementations are empty. That is, they do absolutely nothing.
> 
> They're only mentioned a couple times in the JDK, in CORBA (!) and in some 
> RMI tests (!), and in a few symbol files. On grepcode.com, there are a couple 
> uses, mainly attempting to enable these in response to some debugging flag 
> being given.
> 
> Thus, I propose these be deprecated for removal. Please review diff below.

+1

Mandy

Re: RFR(s): 8153330: deprecate Runtime.traceInstructions & traceMethodCalls for removal

[Alan Bateman]

On 19/04/2016 23:11, Stuart Marks wrote:

Hi all,

I missed a couple bits of cruft in the previous round of java.lang 
deprecations: the Runtime.traceInstructions() and traceMethodCalls() 
methods.

This looks fine.

-Alan

Re: RFR: 8154231: Simplify access to System properties from JDK code

[Claes Redestad]

On 2016-04-20 20:51, Chris Hegarty wrote:

On 20 Apr 2016, at 15:44, Claes Redestad  wrote:


Hello,

now that the sun.security.action package is encapsulated we can simplify 
internal code to get System properties.

Bug: https://bugs.openjdk.java.net/browse/JDK-8154231
Webrev: http://cr.openjdk.java.net/~redestad/8154231/webrev.01/

This looks very nice.


Thanks!



Did you accidentally remove supportsTransparentAuth in the unix version
of NTLMAuthentication.java ? It is used reflectively by
sun.net.www.protocol.http.NTLMAuthenticationProxy. Otherwise, this looks
fine to me.


Oops, nice catch. Updated.

/Claes

Re: RFR: 8154231: Simplify access to System properties from JDK code

[Chris Hegarty]

On 20 Apr 2016, at 15:44, Claes Redestad  wrote:

> Hello,
> 
> now that the sun.security.action package is encapsulated we can simplify 
> internal code to get System properties.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8154231
> Webrev: http://cr.openjdk.java.net/~redestad/8154231/webrev.01/

This looks very nice.

Did you accidentally remove supportsTransparentAuth in the unix version 
of NTLMAuthentication.java ? It is used reflectively by 
sun.net.www.protocol.http.NTLMAuthenticationProxy. Otherwise, this looks
fine to me.

-Chris.

Note to self; I need to revisit the sun.reflect properties.



> This adds a few convenience methods to GetPropertyAction[1] and 
> GetIntegerAction[2]. Since the code calling into this can be streamlined, 
> this leads to a net static footprint reduction of the java.base module and a 
> tiny startup improvement.
> 
> Thanks!
> 
> /Claes
> 
> [1] 
> http://cr.openjdk.java.net/~redestad/8154231/webrev.01/src/java.base/share/classes/sun/security/action/GetPropertyAction.java.udiff.html
> [2] 
> http://cr.openjdk.java.net/~redestad/8154231/webrev.01/src/java.base/share/classes/sun/security/action/GetIntegerAction.java.udiff.html

Re: RFR: 8154231: Simplify access to System properties from JDK code

[Ulf Zibis]

Hi Claes, thanks.

Am 20.04.2016 um 18:12 schrieb Claes Redestad:

Thanks for looking at this, Ulf!

- Isn't the "theProp" naming style something from an old usage where all members have been named 
myXyz? I more would like "propName" or just "property".


I chose to go with keeping names in line with existing methods. If anything is to be done about 
this I'd prefer changing all names in the class to be consistent and modern, and that'd be a 
separate RFE.


Oops, I didn't notice that.
... and semantically more precise would be: "propKey" or "propID".

-Ulf

Re: RFR: 8154231: Simplify access to System properties from JDK code

[Claes Redestad]

Thanks for looking at this, Ulf!

On 2016-04-20 17:57, Ulf Zibis wrote:

Hi,

here my comments:

Am 20.04.2016 um 16:44 schrieb Claes Redestad:

Hello,

now that the sun.security.action package is encapsulated we can 
simplify internal code to get System properties.


Bug: https://bugs.openjdk.java.net/browse/JDK-8154231
Webrev: http://cr.openjdk.java.net/~redestad/8154231/webrev.01/

This adds a few convenience methods to GetPropertyAction[1] and 
GetIntegerAction[2].


- In the original version of ProcessBuilder.java line 472 there was a 
nice example using lambda expression. Wouldn't this be applicable also 
for these new methods here?


While perhaps a nice example in isolation, creating a lambda when 
there's already a specialized convenience class available expressing the 
same thing doesn't add any value.


- Isn't the "theProp" naming style something from an old usage where 
all members have been named myXyz? I more would like "propName" or 
just "property".


I chose to go with keeping names in line with existing methods. If 
anything is to be done about this I'd prefer changing all names in the 
class to be consistent and modern, and that'd be a separate RFE.


- In Integer.getProperty the default substitution is done twice, 
lines: 143, 148. So maybe return to the "immediate return in if...else 
clause" style.


The call to Integer.getInteger on line 143 was supposed to be without 
the defaultVal param to avoid always boxing the defaultVal. Fixed in-place.


Thanks!

/Claes

Re: Locks implementing Closable

[Pavel Rappo]

Here's a bit of background for you to explore:

  
http://stackoverflow.com/questions/16574353/any-risk-in-a-autocloseable-wrapper-for-java-util-concurrent-locks-lock
  http://cs.oswego.edu/pipermail/lambda-lib/2012-June/000447.html
  https://bugs.openjdk.java.net/browse/JDK-7084550

I'm sure if you google it, you'll find more. Much, much more.

> On 20 Apr 2016, at 14:45, kurtymckurt  wrote:
> 
> Has it been considered to have the Lock interface use AutoCloseable?  That
> way users can lock in a try and not have to worry about a finally?
> 
> 
> 
> --
> View this message in context: 
> http://openjdk.5641.n7.nabble.com/Locks-implementing-Closable-tp267580.html
> Sent from the OpenJDK Core Libraries mailing list archive at Nabble.com.

Re: Locks implementing Closable

[kurtymckurt]

Thank you very much for the background.



--
View this message in context: 
http://openjdk.5641.n7.nabble.com/Locks-implementing-Closable-tp267580p267599.html
Sent from the OpenJDK Core Libraries mailing list archive at Nabble.com.

Re: RFR: 8154231: Simplify access to System properties from JDK code

[Ulf Zibis]

Hi,

here my comments:

Am 20.04.2016 um 16:44 schrieb Claes Redestad:

Hello,

now that the sun.security.action package is encapsulated we can simplify internal code to get 
System properties.


Bug: https://bugs.openjdk.java.net/browse/JDK-8154231
Webrev: http://cr.openjdk.java.net/~redestad/8154231/webrev.01/

This adds a few convenience methods to GetPropertyAction[1] and 
GetIntegerAction[2].


- In the original version of ProcessBuilder.java line 472 there was a nice example using lambda 
expression. Wouldn't this be applicable also for these new methods here?
- Isn't the "theProp" naming style something from an old usage where all members have been named 
myXyz? I more would like "propName" or just "property".
- In Integer.getProperty the default substitution is done twice, lines: 143, 148. So maybe return to 
the "immediate return in if...else clause" style.


-Ulf

Re: RFR: JDK-8152690: main thread does not have native thread name

[Yasumasa Suenaga]

Hi Kumar,


Isn't there a management API or something to enumerate the threads ?


On Linux, user apps can get native thread name through pthread_getname_np(3).
However, this function is not called in hotspot and jdk.

So I think it is difficult to get native thread name in all platforms.



Well if it is hard then the jbs must be labelled so, noreg-hard.


I agree to label noreg-hard.


Thanks,

Yasumasa


On 2016/04/20 23:26, Kumar Srinivasan wrote:


On 4/20/2016 6:06 AM, David Holmes wrote:

On 20/04/2016 10:58 PM, Kumar Srinivasan wrote:


Hello,

One more thing, what about a launcher regression test ?


What kind of regression test? I've manually visually inspected the desired 
behaviour but a test for it is very problematic. AFAIK there are no tests for 
setting the native thread name.


Isn't there a management API or something to enumerate the threads ?
I am more worried about some seemingly innocuous launcher change
causing a regression.

Well if it is hard then the jbs must be labelled so, noreg-hard.

Kumar



David


Thanks
Kumar



On 4/19/2016 1:32 PM, David Holmes wrote:

On 20/04/2016 3:00 AM, Kumar Srinivasan wrote:

Hi David,

  493 /* Set native thread name. */
  494 SetNativeThreadName(env, "main");
  495
  496 /* Invoke main method. */
  497 (*env)->CallStaticVoidMethod(env, mainClass, mainID,
mainArgs);

Supposing an exception is thrown in 494 (a very remote case),
will we not re-enter the VM in 497 with an exception ?


Yes as I said:


1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name));
1713 (*env)->CallVoidMethod(env, currentThread, setNativeNameID,
1714nameString, JNI_TRUE);

As above NULL_CHECK is fine here, but we should check for and clear
any pending exception after CallVoidMethod.



Agreed.

Kumar


Thanks,
David


Kumar


On 19/04/2016 10:54 PM, Gerard Ziemski wrote:



On Apr 19, 2016, at 12:04 AM, David Holmes 
wrote:

On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote:

Hi Gerard,

2016/04/19 3:14 "Gerard Ziemski" >:


hi Yasumasa,

Nice work. I have 2 questions:


File: java.c

#1 Shouldn’t we be checking for “(*env)->ExceptionOccurred(env)”

after every single JNI call? In this example instead of NULL_CHECK,
should we be using CHECK_EXCEPTION_NULL_LEAVE macro?

It is not critical if we encounter error at JNI function call
because
we cannot set native thread name only.
So I think that we do not need to leave from launcher process.


I agree we do not need to abort if an exception occurs (and in fact
I don't think an exception is even possible from this code), but we
should ensure any pending exception is cleared before any futher JNI
calls might be made. Note that NULL_CHECK is already used
extensively throughout the launcher code - so if this usage is wrong
then it is all wrong! More on this code below ...


Isn’t there a risk that:

(*env)->CallVoidMethod(env, currentThread, setNativeNameID,
+   nameString, JNI_TRUE);

will raise an exception?

In the least, shouldn’t we clear any possible pending exceptions at
the beginning of “SetNativeThreadName“, as you say, but also at the
very end?


I was actually saying at the end, after the call (even though I don't
think any exceptions are possible - except for "async" exceptions of
course). We shouldn't be able to get to the call with any exception
pending as in that case the JNI calls will be returning NULL and we
will exit - again this pattern is used extensively in the launcher.

David



cheers

Re: RFR: 8154231: Simplify access to System properties from JDK code

[Wang Weijun]

This is quite convenient. We not cover the other modules?

exports sun.security.action to
java.desktop,
java.security.jgss,
jdk.crypto.pkcs11;

Thanks
Max

> On Apr 20, 2016, at 10:44 PM, Claes Redestad  
> wrote:
> 
> Hello,
> 
> now that the sun.security.action package is encapsulated we can simplify 
> internal code to get System properties.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8154231
> Webrev: http://cr.openjdk.java.net/~redestad/8154231/webrev.01/
> 
> This adds a few convenience methods to GetPropertyAction[1] and 
> GetIntegerAction[2]. Since the code calling into this can be streamlined, 
> this leads to a net static footprint reduction of the java.base module and a 
> tiny startup improvement.
> 
> Thanks!
> 
> /Claes
> 
> [1] 
> http://cr.openjdk.java.net/~redestad/8154231/webrev.01/src/java.base/share/classes/sun/security/action/GetPropertyAction.java.udiff.html
> [2] 
> http://cr.openjdk.java.net/~redestad/8154231/webrev.01/src/java.base/share/classes/sun/security/action/GetIntegerAction.java.udiff.html

Locks implementing Closable

[kurtymckurt]

Has it been considered to have the Lock interface use AutoCloseable?  That
way users can lock in a try and not have to worry about a finally?



--
View this message in context: 
http://openjdk.5641.n7.nabble.com/Locks-implementing-Closable-tp267580.html
Sent from the OpenJDK Core Libraries mailing list archive at Nabble.com.

RFR: 8154231: Simplify access to System properties from JDK code

[Claes Redestad]

Hello,

now that the sun.security.action package is encapsulated we can simplify 
internal code to get System properties.


Bug: https://bugs.openjdk.java.net/browse/JDK-8154231
Webrev: http://cr.openjdk.java.net/~redestad/8154231/webrev.01/

This adds a few convenience methods to GetPropertyAction[1] and 
GetIntegerAction[2]. Since the code calling into this can be 
streamlined, this leads to a net static footprint reduction of the 
java.base module and a tiny startup improvement.


Thanks!

/Claes

[1] 
http://cr.openjdk.java.net/~redestad/8154231/webrev.01/src/java.base/share/classes/sun/security/action/GetPropertyAction.java.udiff.html
[2] 
http://cr.openjdk.java.net/~redestad/8154231/webrev.01/src/java.base/share/classes/sun/security/action/GetIntegerAction.java.udiff.html

Re: RFR: JDK-8152690: main thread does not have native thread name

[Kumar Srinivasan]

On 4/20/2016 6:06 AM, David Holmes wrote:

On 20/04/2016 10:58 PM, Kumar Srinivasan wrote:


Hello,

One more thing, what about a launcher regression test ?


What kind of regression test? I've manually visually inspected the 
desired behaviour but a test for it is very problematic. AFAIK there 
are no tests for setting the native thread name.


Isn't there a management API or something to enumerate the threads ?
I am more worried about some seemingly innocuous launcher change
causing a regression.

Well if it is hard then the jbs must be labelled so, noreg-hard.

Kumar



David


Thanks
Kumar



On 4/19/2016 1:32 PM, David Holmes wrote:

On 20/04/2016 3:00 AM, Kumar Srinivasan wrote:

Hi David,

  493 /* Set native thread name. */
  494 SetNativeThreadName(env, "main");
  495
  496 /* Invoke main method. */
  497 (*env)->CallStaticVoidMethod(env, mainClass, mainID,
mainArgs);

Supposing an exception is thrown in 494 (a very remote case),
will we not re-enter the VM in 497 with an exception ?


Yes as I said:


1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name));
1713 (*env)->CallVoidMethod(env, currentThread, setNativeNameID,
1714nameString, JNI_TRUE);

As above NULL_CHECK is fine here, but we should check for and clear
any pending exception after CallVoidMethod.



Agreed.

Kumar


Thanks,
David


Kumar


On 19/04/2016 10:54 PM, Gerard Ziemski wrote:


On Apr 19, 2016, at 12:04 AM, David Holmes 


wrote:

On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote:

Hi Gerard,

2016/04/19 3:14 "Gerard Ziemski" >:


hi Yasumasa,

Nice work. I have 2 questions:


File: java.c

#1 Shouldn’t we be checking for “(*env)->ExceptionOccurred(env)”
after every single JNI call? In this example instead of 
NULL_CHECK,

should we be using CHECK_EXCEPTION_NULL_LEAVE macro?

It is not critical if we encounter error at JNI function call
because
we cannot set native thread name only.
So I think that we do not need to leave from launcher process.


I agree we do not need to abort if an exception occurs (and in 
fact
I don't think an exception is even possible from this code), 
but we
should ensure any pending exception is cleared before any 
futher JNI

calls might be made. Note that NULL_CHECK is already used
extensively throughout the launcher code - so if this usage is 
wrong

then it is all wrong! More on this code below ...


Isn’t there a risk that:

(*env)->CallVoidMethod(env, currentThread, setNativeNameID,
+   nameString, JNI_TRUE);

will raise an exception?

In the least, shouldn’t we clear any possible pending exceptions at
the beginning of “SetNativeThreadName“, as you say, but also at the
very end?


I was actually saying at the end, after the call (even though I 
don't

think any exceptions are possible - except for "async" exceptions of
course). We shouldn't be able to get to the call with any exception
pending as in that case the JNI calls will be returning NULL and we
will exit - again this pattern is used extensively in the launcher.

David



cheers

RFR(S): 8154754: MethodHandles.countedLoop errors in deriving loop arguments, result type, and local state

[Michael Haupt]

Dear all,

please review this change. It depends on the one about 8154751 posted earlier 
[1].
Bug: https://bugs.openjdk.java.net/browse/JDK-8154754
Webrev: http://cr.openjdk.java.net/~mhaupt/8154754/webrev.00/

Thanks,

Michael

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040386.html

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment

RFR(S): 8154751: MethodHandles.countedLoop does not accept empty bodies

[Michael Haupt]

Dear all,

please review this change.
Bug: https://bugs.openjdk.java.net/browse/JDK-8154751
Webrev: http://cr.openjdk.java.net/~mhaupt/8154751/webrev.00/

Thanks,

Michael

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR: JDK-8152690: main thread does not have native thread name

[David Holmes]

On 20/04/2016 10:58 PM, Kumar Srinivasan wrote:


Hello,

One more thing, what about a launcher regression test ?


What kind of regression test? I've manually visually inspected the 
desired behaviour but a test for it is very problematic. AFAIK there are 
no tests for setting the native thread name.


David


Thanks
Kumar



On 4/19/2016 1:32 PM, David Holmes wrote:

On 20/04/2016 3:00 AM, Kumar Srinivasan wrote:

Hi David,

  493 /* Set native thread name. */
  494 SetNativeThreadName(env, "main");
  495
  496 /* Invoke main method. */
  497 (*env)->CallStaticVoidMethod(env, mainClass, mainID,
mainArgs);

Supposing an exception is thrown in 494 (a very remote case),
will we not re-enter the VM in 497 with an exception ?


Yes as I said:


1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name));
1713 (*env)->CallVoidMethod(env, currentThread, setNativeNameID,
1714nameString, JNI_TRUE);

As above NULL_CHECK is fine here, but we should check for and clear
any pending exception after CallVoidMethod.



Agreed.

Kumar


Thanks,
David


Kumar


On 19/04/2016 10:54 PM, Gerard Ziemski wrote:



On Apr 19, 2016, at 12:04 AM, David Holmes 
wrote:

On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote:

Hi Gerard,

2016/04/19 3:14 "Gerard Ziemski" >:


hi Yasumasa,

Nice work. I have 2 questions:


File: java.c

#1 Shouldn’t we be checking for “(*env)->ExceptionOccurred(env)”

after every single JNI call? In this example instead of NULL_CHECK,
should we be using CHECK_EXCEPTION_NULL_LEAVE macro?

It is not critical if we encounter error at JNI function call
because
we cannot set native thread name only.
So I think that we do not need to leave from launcher process.


I agree we do not need to abort if an exception occurs (and in fact
I don't think an exception is even possible from this code), but we
should ensure any pending exception is cleared before any futher JNI
calls might be made. Note that NULL_CHECK is already used
extensively throughout the launcher code - so if this usage is wrong
then it is all wrong! More on this code below ...


Isn’t there a risk that:

(*env)->CallVoidMethod(env, currentThread, setNativeNameID,
+   nameString, JNI_TRUE);

will raise an exception?

In the least, shouldn’t we clear any possible pending exceptions at
the beginning of “SetNativeThreadName“, as you say, but also at the
very end?


I was actually saying at the end, after the call (even though I don't
think any exceptions are possible - except for "async" exceptions of
course). We shouldn't be able to get to the call with any exception
pending as in that case the JNI calls will be returning NULL and we
will exit - again this pattern is used extensively in the launcher.

David



cheers

Re: RFR: JDK-8152690: main thread does not have native thread name

[Kumar Srinivasan]

Hello,

One more thing, what about a launcher regression test ?

Thanks
Kumar



On 4/19/2016 1:32 PM, David Holmes wrote:

On 20/04/2016 3:00 AM, Kumar Srinivasan wrote:

Hi David,

  493 /* Set native thread name. */
  494 SetNativeThreadName(env, "main");
  495
  496 /* Invoke main method. */
  497 (*env)->CallStaticVoidMethod(env, mainClass, mainID, 
mainArgs);


Supposing an exception is thrown in 494 (a very remote case),
will we not re-enter the VM in 497 with an exception ?


Yes as I said:


1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name));
1713 (*env)->CallVoidMethod(env, currentThread, setNativeNameID,
1714nameString, JNI_TRUE);

As above NULL_CHECK is fine here, but we should check for and clear 
any pending exception after CallVoidMethod.



Agreed.

Kumar


Thanks,
David


Kumar


On 19/04/2016 10:54 PM, Gerard Ziemski wrote:



On Apr 19, 2016, at 12:04 AM, David Holmes 
wrote:

On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote:

Hi Gerard,

2016/04/19 3:14 "Gerard Ziemski" >:


hi Yasumasa,

Nice work. I have 2 questions:


File: java.c

#1 Shouldn’t we be checking for “(*env)->ExceptionOccurred(env)”

after every single JNI call? In this example instead of NULL_CHECK,
should we be using CHECK_EXCEPTION_NULL_LEAVE macro?

It is not critical if we encounter error at JNI function call  
because

we cannot set native thread name only.
So I think that we do not need to leave from launcher process.


I agree we do not need to abort if an exception occurs (and in fact
I don't think an exception is even possible from this code), but we
should ensure any pending exception is cleared before any futher JNI
calls might be made. Note that NULL_CHECK is already used
extensively throughout the launcher code - so if this usage is wrong
then it is all wrong! More on this code below ...


Isn’t there a risk that:

(*env)->CallVoidMethod(env, currentThread, setNativeNameID,
+   nameString, JNI_TRUE);

will raise an exception?

In the least, shouldn’t we clear any possible pending exceptions at
the beginning of “SetNativeThreadName“, as you say, but also at the
very end?


I was actually saying at the end, after the call (even though I don't
think any exceptions are possible - except for "async" exceptions of
course). We shouldn't be able to get to the call with any exception
pending as in that case the JNI calls will be returning NULL and we
will exit - again this pattern is used extensively in the launcher.

David



cheers

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

[Paul Sandoz]

> On 20 Apr 2016, at 13:50, Tagir F. Valeev  wrote:
> 
> Hello!
> 
> PS> Thinking some more about this, i think it would be preferable. It
> PS> reduces the explicit referral to
> PS> ForkJoinPool.getCommonPoolParallelism().
> 
> No problems, here's updated webrev:
> http://cr.openjdk.java.net/~tvaleev/webrev/8154387/r2/
> All tests pass.
> 

Thanks, in my queue, as if your other webrev.

Paul.

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

[Tagir F. Valeev]

Hello!

PS> Thinking some more about this, i think it would be preferable. It
PS> reduces the explicit referral to
PS> ForkJoinPool.getCommonPoolParallelism().

No problems, here's updated webrev:
http://cr.openjdk.java.net/~tvaleev/webrev/8154387/r2/
All tests pass.

With best regards,
Tagir Valeev.

RFR(S): 8152667: MHs.iteratedLoop(...) throws unexpected WMTE, disallows Iterator subclasses, generates inconsistent loop result type

[Michael Haupt]

Dear all,

please review this change.
Bug: https://bugs.openjdk.java.net/browse/JDK-8152667
Webrev: http://cr.openjdk.java.net/~mhaupt/8152667/webrev.00/

Thanks,

Michael

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

[Paul Sandoz]

> On 19 Apr 2016, at 18:57, Paul Sandoz  wrote:
>> The LEAF_TARGET version does not change the results significantly. If
>> you feel that using LEAF_TARGET is more suitable I can update webrev
>> correspondingly.
>> 
> 
> It has some appeal, since there is a symmetry to using that and the threshold 
> at which the wrapping spliterator will no longer be split by F/J tasks. Up to 
> you.
> 

Thinking some more about this, i think it would be preferable. It reduces the 
explicit referral to ForkJoinPool.getCommonPoolParallelism().

In general the binding the the common pool is an something we want to relax, 
but its tricky to come up with a sane parallel policy mechanism.

Paul.

Re: RFR: 8072921: -Xincgc should be removed from output

[Stefan Karlsson]

On 2016-04-19 12:45, Alan Bateman wrote:



On 19/04/2016 10:58, Stefan Karlsson wrote:


I've left the locale specific launcher files untouched. Should I 
update them as well?
Dropping -Xincgc rom the -X output looks okay to me. We usually don't 
touch the translations as they are updated in bulk periodically, often 
closer to the end a release.


OK. Thanks for the review.

StefanK



-Alan.

RE: RFR: JDK-8153781 Issue in XMLScanner: EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large DOCTYPE section with CRLF at wrong place

[Langer, Christoph]

Thanks Joe :-)

> -Original Message-
> From: huizhe wang [mailto:huizhe.w...@oracle.com]
> Sent: Dienstag, 19. April 2016 23:44
> To: Langer, Christoph 
> Cc: core-libs-dev@openjdk.java.net
> Subject: Re: RFR: JDK-8153781 Issue in XMLScanner:
> EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping
> large DOCTYPE section with CRLF at wrong place
> 
> 
> On 4/19/2016 1:45 PM, Langer, Christoph wrote:
> > Hi Joe,
> >
> >>> I've updated the testcase to increase the probability of it really 
> >>> hitting the
> >> issue. The old version was prone to miss the issue in case something
> changed in
> >> the parser.
> >>> http://cr.openjdk.java.net/~clanger/webrevs/8153781.2/
> >> Looks good overall.
> > OK, thanks.
> >
> >> Error msgs:  you made an extra effort :-)  normally, we don't need to do
> >> any translation. The I18n team has a revolving task that will
> >> periodically pick up these changes.
> > OK - I think the message is not really useful anyway. I don't see a way to
> produce it by creating a malformed XML document. It would probably only pop
> up with the old erroneous implementation of skipDTD and SUPPORT_DTD
> property false.
> >
> >> License header: it is correct to update to the latest Apache License
> >> format. However, we would need to preserve the "reserved comment block"
> >> if we've not changed the code, which is the case for class such as
> >> HTTPInputSource.java.
> > Fixed that.
> >
> > Here is the new webrev:
> http://cr.openjdk.java.net/~clanger/webrevs/8153781.3/
> >
> > If you consider it reviewed I would love if you could push it for me. :-)
> 
> Sure :-)  Will do after all test runs complete.
> 
> Thanks,
> Joe
> 
> >
> > Thanks
> > Christoph
> >