Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Thomas Stüfe]

Hi,

This was added by "8200178: Remove mapfiles for JDK native libraries".
But if the flag is not accepted, what is the default behavior? Do we
now export everything?

I'd like to understand this first before removing the flag to get rid
of the warnings.

Best Regards, Thomas

On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis
 wrote:
> Hi Matthias,
>
> after Bhaktavatsal Reddy's report about the problems with
> "-qvisibility" with xlC 13 and taking into account that we can't test
> this anyway because we don't currently have xlC 13
>  on our machines I think it would be best to completely remove this
> option for now on AIX. Once we get xlC 13 we can revisit the issue.
>
> Thanks,
> Volker
>
>
> On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram
>  wrote:
>> Hi Matthias,
>>
>> At this point, I think we can remove the flag as you found that it is not 
>> supported in XLC < 13. And with XLC 13, it require more work to use this 
>> flag.
>>
>> Thanks,
>> Bhaktavatsal Reddy
>>
>>
>>
>> -"Baesken, Matthias"  wrote: -
>> To: "Langer, Christoph" , 
>> "'build-...@openjdk.java.net'" , 
>> "ppc-aix-port-...@openjdk.java.net" , 
>> "core-libs-dev@openjdk.java.net" 
>> From: "Baesken, Matthias" 
>> Date: 04/26/2018 08:23PM
>> Cc: "Simonis, Volker" , Bhaktavatsal R Maram
>> 
>> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
>> 12.1
>>
>>
>>  Hello Christoph,   I think  all XLC versions  < 12.1   are unsupported  
>> (and probably not working anyway)  for the OpenJDK  build .
>>  I am only aware   of  XLC  versions  12.1  and 13.1which  work / in 
>> case of 13.1  “might” work   for OpenJDK compilation .
>>  And for 12.1  I want to remove the flags  .
>>
>>  ( waiting for the feedback  of   Bhaktavatsal Reddy ,  in case he  prefers 
>> it  I remove them for all xlC versions including 13.1 )
>>
>>  Best regards, Matthias
>>
>>
>>
>>
>>
>>
>>  From: Langer, Christoph
>>  Sent: Donnerstag, 26. April 2018 16:38
>>  To: Baesken, Matthias ; 
>> 'build-...@openjdk.java.net' ; 
>> ppc-aix-port-...@openjdk.java.net; core-libs-dev@openjdk.java.net
>>  Cc: Simonis, Volker 
>>  Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
>> 12.1
>>
>>  Hi Matthias,
>>
>>  to me the change in principal looks good.
>>
>>  I’m wondering if it is possible to do a comparison like xlc < 13 (e.g. 
>> extract major number before the first dot, then compare numerically) – but 
>> maybe it is too complicated and the current single version compare suits  
>> our needs ?
>>
>>  Best regards
>>  Christoph
>>
>>
>>
>>
>>  From: Baesken, Matthias
>>  Sent: Donnerstag, 26. April 2018 16:14
>>  To: 'build-...@openjdk.java.net' ; 
>> ppc-aix-port-...@openjdk.java.net; core-libs-dev@openjdk.java.net
>>  Cc: Langer, Christoph ; Simonis, Volker 
>> 
>>  Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1
>>
>>  Hello  ,  could you please review this small adjustment to  the symbol 
>> visibility compilation settings on AIX ?
>>  Currently  we use  XLC 12.1  to compile  JDK on AIX .
>>
>>  However XLC 12.1   does not support  the “-qvisibility=hidden”  setting 
>> currently set on AIX.
>>  It was introduced with  XLC 13.1 . Christoph found some info about it here :
>>
>>  
>> https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html
>>
>>  Setting it  only generates  hundreds  of warnings  in the build log , 
>> warnings look like this :
>>  XlC12.1
>>
>>  bash-4.4$ xlC -qversion
>>  IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)
>>  Version: 12.01..0019
>>
>>  bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
>>  1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of 
>> valid options.
>>
>>  Compare to XLC13.1
>>
>>  bash-3.00$ xlC -qversion
>>  IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07)
>>  Version: 13.01..0008
>>  bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
>>  bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
>>
>>
>>  So it is better to avoid  setting these flags when using xlc12.1   .
>>  Please review :
>>
>>  Bug :
>>
>>  https://bugs.openjdk.java.net/browse/JDK-8202322
>>
>>  Change :
>>
>>  http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/
>>
>>
>>  Best regards, Matthias
>>
>>
>>
>>

RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents

[Joe Wang]

Hi,

Considering extending isSameFile to add isSameContent to Files. Please 
review.


JBS: https://bugs.openjdk.java.net/browse/JDK-8202285

webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/

specdiff: 
http://cr.openjdk.java.net/~joehw/jdk11/8202285/specdiff/java/nio/file/Files.html


Thanks,
Joe

RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

[Joe Wang]

Hi,

We're looking into adding methods to Files to read a file into a 
String/write a String to a file. Below is the current proposal. Please 
review.


JBS: https://bugs.openjdk.java.net/browse/JDK-8201276

webrev: http://cr.openjdk.java.net/~joehw/jdk11/8201276/webrev/

specdiff: 
http://cr.openjdk.java.net/~joehw/jdk11/8201276/specdiff/java/nio/file/Files.html



Thanks,
Joe

Re: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled

[Xueming Shen]

+1

(nit: remove the "where:" and the corresponding indent before push please).


On 4/26/18, 1:34 PM, Jan Lahoda wrote:



Ok, here is an updated webrev:
http://cr.openjdk.java.net/~jlahoda/8202105/webrev.02/

Jan

Re: (M) RFR: 8200167: Validate more special case invocations

[David Holmes]

Thanks Karen!

Once my re-testing has completed I'll look at pushing this.

David

On 27/04/2018 7:21 AM, Karen Kinnear wrote:

Looks good!

Thank you so much David and Vladimir for all the work to cover the corner cases.

thanks,
Karen


On Apr 26, 2018, at 12:12 AM, David Holmes  wrote:

Revised webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev.v2/

Karen formulated an additional test scenario invoking Object methods through an 
interface reference, which when turned into a new testcase demonstrated that 
the receiver typecheck was also missing in that case for Methodhandle's from 
findSpecial.

Again Vladimir Ivanov formulated the fix for this. Thanks Vladimir!

Summary of changes from original webrev:

- We introduce a new version of DirectMethodHandle.preparedlambdaForm that 
takes the caller class as a parameter, and that class is checked for being an 
interface (not the method's declaring class) to trigger the switch to 
LF_SPECIAL_IFC. (This obviously addresses one problem with invoking Object 
methods - as Object is not an interface - but by itself did not fix the 
problem.)

- We introduce a new LambdaForm kind, DIRECT_INVOKE_SPECIAL_IFC, which we use 
when dealing with LF_INVSPECIAL_IFC. (This was the key in ensuring the receiver 
typecheck via Special.checkReceiver remained in the generated code.)

- In the test we:
  - introduce a new invokeDirect testcase for Object.toString(), but we need to 
do that via a modified jcod file (as javac generates an invokevirtual)
  - introduce the new invokeSpecialObjectMH(I2 i) call for the MH case.

Thanks,
David

On 17/04/2018 6:48 PM, David Holmes wrote:

Bug: https://bugs.openjdk.java.net/browse/JDK-8200167
webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/
Credit to John Rose and Vladimir Ivanov for the form of the MH fix; and to 
Tobias Hartmann for the C1 fix. Their help was very much appreciated (and 
needed!).
tl;dr version: there are some places where badly formed interface method calls 
(which are not detected by the verifier) were missing runtime checks on the 
type of the receiver. Similar issues have been fixed in the past and this was a 
remaining hole in relation to invokespecial semantics and interface calls via 
MethodHandles. It also turned out there was an issue in C1 that affected direct 
invokespecial calls.
Description of changes:
- src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java
Added a new form LF_INVSPECIAL_IFC for invokespecial of interface methods.
- src/java.base/share/classes/java/lang/invoke/MethodHandles.java
Renamed callerClass parameter to boundCallerClass, where it originates from 
findBoundCallerClass. The name "callerClass" is misleading because most of the 
time it is NULL!
In getDirectMethodCommon, pass the actual caller class (lookupClass) to 
DirectMethodHandle.make. And correct the comment about restrictReceiver.
- src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
DirectMethodHandle.make now takes a callerClass parameter (which may be null).
DirectMethodHandle make "receiver" parameter is renamed "refc" as it is not the 
receiver (it's the resolved type of the method holder ie REFC).
The Special subclass now takes a "checkClass" parameter which is either refc, 
or callerClass. This is what we will check the receiver against.
In preparedLambdaForm we switch from LF_INVSPECIAL to LF_INVSPECIAL_IFC if the 
target method is in an interface.
In makePreparedLambdaForm we augment the needsReceiverCheck test to include 
LF_INVSPECIAL_IFC. (So we will not be doing a new receiver type check on all 
invokespecials, just those involving interface methods.)
Added DMH.checkReceiver which is overridden by both the Special and Interface 
subclasses.
- src/hotspot/share/c1/c1_Canonicalizer.cpp
Don't optimize away the checkcast when it is an invokespecial receiver check.
- test/jdk/java/lang/invoke/SpecialInterfaceCall.java
(I've moved this test back and forth between hotspot/runtime and j.l.invoke as 
it spans direct calls and MH calls. But I think on balance it lands better 
here.)
The test sets up direct interface method calls for which invokespecial is 
generated by javac, and similarly it creates MethodHandles with invokespecial 
semantics. The should-not-throw cases are trivial. The should-throw cases 
involve MH wizardry.
The test is broken into three parts to check the behaviour on first use (when 
the method has to be initially resolved); on second use (to test we don't use 
the cpcache in a way that is invalid); and again after forcing JIT compilation 
of the calls.
The test is run 5 times to exercise the interpreter (yes the multiple runs 
internal to the test are redundant in this case, but it's much simpler to just 
run it all than try to work out what needs to be run); the three variants of 
using C1, plus a C2 only run.
---
Testing:
   - the new test of course
   - hotspot/runtime/*
   - hotspot/compiler/jsr292
   - jdk/java/lang/invoke
   

Re: (M) RFR: 8200167: Validate more special case invocations

[David Holmes]

Hi Vladimir,

On 27/04/2018 7:07 AM, Vladimir Ivanov wrote:

David, thanks for taking care of the bug!


Thanks for all the help!


src/hotspot/share/c1/c1_Canonicalizer.cpp
...
  void Canonicalizer::do_CheckCast  (CheckCast*   x) {
-  if (x->klass()->is_loaded()) {
+  if (x->klass()->is_loaded() && !x->is_invokespecial_receiver_check())

It seems like it's not something specific to invokespecial, but a 
generic problem in how interface casts are handled in C1: it's not 
correct to eliminate the cast if obj->declared_type() is an interface. I 
assume that's what happens in your case. FTR I'm fine with handling it 
separately.


The above came from Tobias. If you think there is a more general issue 
here then we should file a separate bug and formulate a test case.



test/jdk/java/lang/invoke/I4Special.jcod:

I'm curious why did you choose jcod here and not jasm? It seems jasm 
should be a better fit to replace invokevirtual with invokespecial 
(unless I'm missing something important in the test case).


Simply because jcod is what I have been working with in nestmates for 
classfile customizations and I don't know jasm.



Otherwise, looks good.


Thanks again!

David



Best regards,
Vladimir Ivanov

On 4/25/18 21:12, David Holmes wrote:

Revised webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev.v2/

Karen formulated an additional test scenario invoking Object methods 
through an interface reference, which when turned into a new testcase 
demonstrated that the receiver typecheck was also missing in that case 
for Methodhandle's from findSpecial.


Again Vladimir Ivanov formulated the fix for this. Thanks Vladimir!

Summary of changes from original webrev:

- We introduce a new version of DirectMethodHandle.preparedlambdaForm 
that takes the caller class as a parameter, and that class is checked 
for being an interface (not the method's declaring class) to trigger 
the switch to LF_SPECIAL_IFC. (This obviously addresses one problem 
with invoking Object methods - as Object is not an interface - but by 
itself did not fix the problem.)


- We introduce a new LambdaForm kind, DIRECT_INVOKE_SPECIAL_IFC, which 
we use when dealing with LF_INVSPECIAL_IFC. (This was the key in 
ensuring the receiver typecheck via Special.checkReceiver remained in 
the generated code.)


- In the test we:
   - introduce a new invokeDirect testcase for Object.toString(), but 
we need to do that via a modified jcod file (as javac generates an 
invokevirtual)

   - introduce the new invokeSpecialObjectMH(I2 i) call for the MH case.

Thanks,
David

On 17/04/2018 6:48 PM, David Holmes wrote:

Bug: https://bugs.openjdk.java.net/browse/JDK-8200167
webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/

Credit to John Rose and Vladimir Ivanov for the form of the MH fix; 
and to Tobias Hartmann for the C1 fix. Their help was very much 
appreciated (and needed!).


tl;dr version: there are some places where badly formed interface 
method calls (which are not detected by the verifier) were missing 
runtime checks on the type of the receiver. Similar issues have been 
fixed in the past and this was a remaining hole in relation to 
invokespecial semantics and interface calls via MethodHandles. It 
also turned out there was an issue in C1 that affected direct 
invokespecial calls.


Description of changes:

- src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java

Added a new form LF_INVSPECIAL_IFC for invokespecial of interface 
methods.


- src/java.base/share/classes/java/lang/invoke/MethodHandles.java

Renamed callerClass parameter to boundCallerClass, where it 
originates from findBoundCallerClass. The name "callerClass" is 
misleading because most of the time it is NULL!


In getDirectMethodCommon, pass the actual caller class (lookupClass) 
to DirectMethodHandle.make. And correct the comment about 
restrictReceiver.


- src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java

DirectMethodHandle.make now takes a callerClass parameter (which may 
be null).


DirectMethodHandle make "receiver" parameter is renamed "refc" as it 
is not the receiver (it's the resolved type of the method holder ie 
REFC).


The Special subclass now takes a "checkClass" parameter which is 
either refc, or callerClass. This is what we will check the receiver 
against.


In preparedLambdaForm we switch from LF_INVSPECIAL to 
LF_INVSPECIAL_IFC if the target method is in an interface.


In makePreparedLambdaForm we augment the needsReceiverCheck test to 
include LF_INVSPECIAL_IFC. (So we will not be doing a new receiver 
type check on all invokespecials, just those involving interface 
methods.)


Added DMH.checkReceiver which is overridden by both the Special and 
Interface subclasses.


- src/hotspot/share/c1/c1_Canonicalizer.cpp

Don't optimize away the checkcast when it is an invokespecial 
receiver check.


- test/jdk/java/lang/invoke/SpecialInterfaceCall.java

(I've moved this test back and forth between 

Re: (M) RFR: 8200167: Validate more special case invocations

[Karen Kinnear]

Looks good!

Thank you so much David and Vladimir for all the work to cover the corner cases.

thanks,
Karen

> On Apr 26, 2018, at 12:12 AM, David Holmes  wrote:
> 
> Revised webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev.v2/
> 
> Karen formulated an additional test scenario invoking Object methods through 
> an interface reference, which when turned into a new testcase demonstrated 
> that the receiver typecheck was also missing in that case for Methodhandle's 
> from findSpecial.
> 
> Again Vladimir Ivanov formulated the fix for this. Thanks Vladimir!
> 
> Summary of changes from original webrev:
> 
> - We introduce a new version of DirectMethodHandle.preparedlambdaForm that 
> takes the caller class as a parameter, and that class is checked for being an 
> interface (not the method's declaring class) to trigger the switch to 
> LF_SPECIAL_IFC. (This obviously addresses one problem with invoking Object 
> methods - as Object is not an interface - but by itself did not fix the 
> problem.)
> 
> - We introduce a new LambdaForm kind, DIRECT_INVOKE_SPECIAL_IFC, which we use 
> when dealing with LF_INVSPECIAL_IFC. (This was the key in ensuring the 
> receiver typecheck via Special.checkReceiver remained in the generated code.)
> 
> - In the test we:
>  - introduce a new invokeDirect testcase for Object.toString(), but we need 
> to do that via a modified jcod file (as javac generates an invokevirtual)
>  - introduce the new invokeSpecialObjectMH(I2 i) call for the MH case.
> 
> Thanks,
> David
> 
> On 17/04/2018 6:48 PM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200167
>> webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/
>> Credit to John Rose and Vladimir Ivanov for the form of the MH fix; and to 
>> Tobias Hartmann for the C1 fix. Their help was very much appreciated (and 
>> needed!).
>> tl;dr version: there are some places where badly formed interface method 
>> calls (which are not detected by the verifier) were missing runtime checks 
>> on the type of the receiver. Similar issues have been fixed in the past and 
>> this was a remaining hole in relation to invokespecial semantics and 
>> interface calls via MethodHandles. It also turned out there was an issue in 
>> C1 that affected direct invokespecial calls.
>> Description of changes:
>> - src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java
>> Added a new form LF_INVSPECIAL_IFC for invokespecial of interface methods.
>> - src/java.base/share/classes/java/lang/invoke/MethodHandles.java
>> Renamed callerClass parameter to boundCallerClass, where it originates from 
>> findBoundCallerClass. The name "callerClass" is misleading because most of 
>> the time it is NULL!
>> In getDirectMethodCommon, pass the actual caller class (lookupClass) to 
>> DirectMethodHandle.make. And correct the comment about restrictReceiver.
>> - src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
>> DirectMethodHandle.make now takes a callerClass parameter (which may be 
>> null).
>> DirectMethodHandle make "receiver" parameter is renamed "refc" as it is not 
>> the receiver (it's the resolved type of the method holder ie REFC).
>> The Special subclass now takes a "checkClass" parameter which is either 
>> refc, or callerClass. This is what we will check the receiver against.
>> In preparedLambdaForm we switch from LF_INVSPECIAL to LF_INVSPECIAL_IFC if 
>> the target method is in an interface.
>> In makePreparedLambdaForm we augment the needsReceiverCheck test to include 
>> LF_INVSPECIAL_IFC. (So we will not be doing a new receiver type check on all 
>> invokespecials, just those involving interface methods.)
>> Added DMH.checkReceiver which is overridden by both the Special and 
>> Interface subclasses.
>> - src/hotspot/share/c1/c1_Canonicalizer.cpp
>> Don't optimize away the checkcast when it is an invokespecial receiver check.
>> - test/jdk/java/lang/invoke/SpecialInterfaceCall.java
>> (I've moved this test back and forth between hotspot/runtime and j.l.invoke 
>> as it spans direct calls and MH calls. But I think on balance it lands 
>> better here.)
>> The test sets up direct interface method calls for which invokespecial is 
>> generated by javac, and similarly it creates MethodHandles with 
>> invokespecial semantics. The should-not-throw cases are trivial. The 
>> should-throw cases involve MH wizardry.
>> The test is broken into three parts to check the behaviour on first use 
>> (when the method has to be initially resolved); on second use (to test we 
>> don't use the cpcache in a way that is invalid); and again after forcing JIT 
>> compilation of the calls.
>> The test is run 5 times to exercise the interpreter (yes the multiple runs 
>> internal to the test are redundant in this case, but it's much simpler to 
>> just run it all than try to work out what needs to be run); the three 
>> variants of using C1, plus a C2 only run.
>> ---
>> Testing:
>>   - the 

Re: (M) RFR: 8200167: Validate more special case invocations

[Vladimir Ivanov]

David, thanks for taking care of the bug!

src/hotspot/share/c1/c1_Canonicalizer.cpp
...
 void Canonicalizer::do_CheckCast  (CheckCast*   x) {
-  if (x->klass()->is_loaded()) {
+  if (x->klass()->is_loaded() && !x->is_invokespecial_receiver_check())

It seems like it's not something specific to invokespecial, but a 
generic problem in how interface casts are handled in C1: it's not 
correct to eliminate the cast if obj->declared_type() is an interface. I 
assume that's what happens in your case. FTR I'm fine with handling it 
separately.


test/jdk/java/lang/invoke/I4Special.jcod:

I'm curious why did you choose jcod here and not jasm? It seems jasm 
should be a better fit to replace invokevirtual with invokespecial 
(unless I'm missing something important in the test case).


Otherwise, looks good.


Best regards,
Vladimir Ivanov

On 4/25/18 21:12, David Holmes wrote:

Revised webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev.v2/

Karen formulated an additional test scenario invoking Object methods 
through an interface reference, which when turned into a new testcase 
demonstrated that the receiver typecheck was also missing in that case 
for Methodhandle's from findSpecial.


Again Vladimir Ivanov formulated the fix for this. Thanks Vladimir!

Summary of changes from original webrev:

- We introduce a new version of DirectMethodHandle.preparedlambdaForm 
that takes the caller class as a parameter, and that class is checked 
for being an interface (not the method's declaring class) to trigger the 
switch to LF_SPECIAL_IFC. (This obviously addresses one problem with 
invoking Object methods - as Object is not an interface - but by itself 
did not fix the problem.)


- We introduce a new LambdaForm kind, DIRECT_INVOKE_SPECIAL_IFC, which 
we use when dealing with LF_INVSPECIAL_IFC. (This was the key in 
ensuring the receiver typecheck via Special.checkReceiver remained in 
the generated code.)


- In the test we:
   - introduce a new invokeDirect testcase for Object.toString(), but we 
need to do that via a modified jcod file (as javac generates an 
invokevirtual)

   - introduce the new invokeSpecialObjectMH(I2 i) call for the MH case.

Thanks,
David

On 17/04/2018 6:48 PM, David Holmes wrote:

Bug: https://bugs.openjdk.java.net/browse/JDK-8200167
webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/

Credit to John Rose and Vladimir Ivanov for the form of the MH fix; 
and to Tobias Hartmann for the C1 fix. Their help was very much 
appreciated (and needed!).


tl;dr version: there are some places where badly formed interface 
method calls (which are not detected by the verifier) were missing 
runtime checks on the type of the receiver. Similar issues have been 
fixed in the past and this was a remaining hole in relation to 
invokespecial semantics and interface calls via MethodHandles. It also 
turned out there was an issue in C1 that affected direct invokespecial 
calls.


Description of changes:

- src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java

Added a new form LF_INVSPECIAL_IFC for invokespecial of interface 
methods.


- src/java.base/share/classes/java/lang/invoke/MethodHandles.java

Renamed callerClass parameter to boundCallerClass, where it originates 
from findBoundCallerClass. The name "callerClass" is misleading 
because most of the time it is NULL!


In getDirectMethodCommon, pass the actual caller class (lookupClass) 
to DirectMethodHandle.make. And correct the comment about 
restrictReceiver.


- src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java

DirectMethodHandle.make now takes a callerClass parameter (which may 
be null).


DirectMethodHandle make "receiver" parameter is renamed "refc" as it 
is not the receiver (it's the resolved type of the method holder ie 
REFC).


The Special subclass now takes a "checkClass" parameter which is 
either refc, or callerClass. This is what we will check the receiver 
against.


In preparedLambdaForm we switch from LF_INVSPECIAL to 
LF_INVSPECIAL_IFC if the target method is in an interface.


In makePreparedLambdaForm we augment the needsReceiverCheck test to 
include LF_INVSPECIAL_IFC. (So we will not be doing a new receiver 
type check on all invokespecials, just those involving interface 
methods.)


Added DMH.checkReceiver which is overridden by both the Special and 
Interface subclasses.


- src/hotspot/share/c1/c1_Canonicalizer.cpp

Don't optimize away the checkcast when it is an invokespecial receiver 
check.


- test/jdk/java/lang/invoke/SpecialInterfaceCall.java

(I've moved this test back and forth between hotspot/runtime and 
j.l.invoke as it spans direct calls and MH calls. But I think on 
balance it lands better here.)


The test sets up direct interface method calls for which invokespecial 
is generated by javac, and similarly it creates MethodHandles with 
invokespecial semantics. The should-not-throw cases are trivial. The 
should-throw cases involve MH wizardry.


The test is 

Re: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled

[Jan Lahoda]

On 26.4.2018 20:09, Xueming Shen wrote:

On 4/26/18, 3:23 AM, Jan Lahoda wrote:

On 25.4.2018 22:59, Xueming Shen wrote:

On 04/25/2018 01:39 PM, Jan Lahoda wrote:

So, if I understand correctly, it would be:
boolean flipEcho;
and the readPassword would do something like:
if (echo0() != false) {


if (echo0()) { ...


flipEcho = true;
echo(false);
}

if (flipEcho) { //this would also be in the shutdown hook
 echo(!echo0());
}


if (flipEcho) {
 echo(true);
 flipEcho = false;
}
?


Hmm, right. It start to look a lot like the original code, with the
exception that the flag is also checked inside readPassword:
http://cr.openjdk.java.net/~jlahoda/8202105/webrev.01/

(This also makes the shutdown hook registration lazy.)

Jan

shouldn't we move the installShutonwHookIfNeeded() into synced block? and
simply name it "installShutdownHook()" ?


Ok, here is an updated webrev:
http://cr.openjdk.java.net/~jlahoda/8202105/webrev.02/

Jan



the rest looks fine.

-sherman

Please review CSR: JDK-8200435 String::stripIndent, String::stripMarkers

[Jim Laskey]

Please review and mark as reviewed 
https://bugs.openjdk.java.net/browse/JDK-8200435

Re: Review Request JDK-8201793: (ref) Reference object should not support cloning

[Paul Sandoz]

Hi Mandy,

This looks reasonable. I suspect external subtypes of the j.l.ref types are 
extremely rare (grep code reports no derived types) and of those it would 
likely be even rarer for those subtypes to implement Cloneable, and for that 
functionality to operate reliably.

Paul. 

> On Apr 26, 2018, at 7:16 AM, mandy chung  wrote:
> 
> The semantics of cloning a Reference object is not clearly defined. In 
> addition, it is questionable whether it can be meaningfully supported in 
> particular with concurrent reference processing.
> 
> The reachability state of a Reference object may change during GC reference 
> processing. The referent may have been cleared when it reaches its 
> reachability state. In addition, it may be enqueued or pending for enqueuing. 
> Cloning a Reference object with a referent that is unreachable but not yet 
> cleared might mean to resurrect the referent. A cloned enqueued Reference 
> object will never be enqueued.  A Reference object cannot be meaningfully 
> cloned.
> 
> We propose Reference::clone to throw CloneNotSupportedException.  To clone a 
> Reference object, it should create a new instance via its constructor.
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8202260
> 
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8201793/webrev.00/
> 
> Mandy

Re: [11] RFR: 8181157: CLDR Timezone name fallback implementation

[Xueming Shen]

+1

On 4/23/18, 6:25 PM, Naoto Sato wrote:

Hi Sherman, thanks for the review.

On 4/23/18 1:06 PM, Xueming Shen wrote:

Naoto,

Here some comments

(1) CLDRTimeZoneNameProviderImpl.java:
  Ln#58:  to use Stream.toArray(String[]::new) ? no sure which 
one is faster


  Ln#155-160:
  is it worth considering to check all possible empty slots 
in "names" here
  (from index_std_long to index_std_short?) to avoid 
check/load "compact" multiple
  times?  it appears doable for deriveFallbackNames() but I'm 
not sure about

  the invocation at #ln100, so a "?".

(2) CLDRConverter.java:
  Ln#674: (not in updated code) why update the "local" jreMetaMap?
just wonder it'd better to use 
Optional.ifPresentOrElse(...) here


  Ln:707:  (don't know which one is better though :-))
  .toMap(Map.Entry::getKey, Map.Entry::getValue);


Addressed all of the above suggestions. Unnecessary jreMetaMap update 
was a good catch!




(3) LocaleResources.java
  just wanted to confirm the "locale.resources.debug" is 
something we wanted to

  be a public interface or not?


Eventually I'd be public (8057075), but it is a private use for the 
time being.


Here's the updated webrev:

http://cr.openjdk.java.net/~naoto/8181157/webrev.06/

Naoto



Thanks,
Sherman


On 04/17/2018 02:28 PM, Naoto Sato wrote:

Hello,

Please review the changes to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8181157

The proposed fix is located at:

http://cr.openjdk.java.net/~naoto/8181157/webrev.05/

This RFE is to implement CLDR time zone names fallback mechanism 
[1]. Prior to this fix, time zone names are substituted with English 
names. With this change, it is generated according to the logic 
defined in TR 35. Here are the highlight of the changes:


CLDRConverter:
- CLDRConverter has changed to not substitute/invent time zone display
names, except English bundle for compatibility & runtime performance.
- For English bundle, copy over COMPAT's names as before.
- CLDRConverer now parses regionFormat/gmtZeroFormat/exemplarCity

CLDR provider:
- CLDRTimeZoneNameProviderImpl is introduced to generate fallback names
at runtime.
- If COMPAT provider is present, use it also as a fallback, before the
last resort (GMT offset format)

Naoto

[1] http://www.unicode.org/reports/tr35/tr35-dates.html#Time_Zone_Names

RFR 8197388: Added not existing bug id in jdk/ProblemList.txt

[Andrey Nazarov]

Hi,

Please review patch that fixes typo in bug id.

diff -r 3661f31c6df4 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt  Thu Apr 26 11:19:05 2018 -0500
+++ b/test/jdk/ProblemList.txt  Thu Apr 26 11:47:18 2018 -0700
@@ -243,7 +243,7 @@
 sun/java2d/SunGraphics2D/EmptyClipRenderingTest.java 8144029 macosx-all
 sun/java2d/SunGraphics2D/DrawImageBilinear.java 8191506 generic-all
 sun/java2d/SunGraphics2D/PolyVertTest.java 6986565 generic-all
-sun/java2d/SunGraphics2D/SimplePrimQuality.java 7992007 generic-all
+sun/java2d/SunGraphics2D/SimplePrimQuality.java 6992007 generic-all
 sun/java2d/SunGraphics2D/SourceClippingBlitTest/SourceClippingBlitTest.java 
8196191 windows-all,macosx-all
 sun/java2d/pipe/InterpolationQualityTest.java 8171303 
windows-all,linux-all,macosx-all
 java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java 8169469 
windows-all

Issue: https://bugs.openjdk.java.net/browse/JDK-8197388


—Thanks,
Andrei

Re: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled

[Xueming Shen]

On 4/26/18, 3:23 AM, Jan Lahoda wrote:

On 25.4.2018 22:59, Xueming Shen wrote:

On 04/25/2018 01:39 PM, Jan Lahoda wrote:

So, if I understand correctly, it would be:
boolean flipEcho;
and the readPassword would do something like:
if (echo0() != false) {


if (echo0()) { ...


flipEcho = true;
echo(false);
}

if (flipEcho) { //this would also be in the shutdown hook
 echo(!echo0());
}


if (flipEcho) {
 echo(true);
 flipEcho = false;
}
?


Hmm, right. It start to look a lot like the original code, with the 
exception that the flag is also checked inside readPassword:

http://cr.openjdk.java.net/~jlahoda/8202105/webrev.01/

(This also makes the shutdown hook registration lazy.)

Jan

shouldn't we move the installShutonwHookIfNeeded() into synced block? and
simply name it "installShutdownHook()" ?

the rest looks fine.

-sherman

Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Erik Joelsson]

Looks ok.

/Erik


On 2018-04-26 07:13, Baesken, Matthias wrote:

Hello  ,  could you please review this small adjustment to  the symbol 
visibility compilation settings on AIX ?
Currently  we use  XLC 12.1  to compile  JDK on AIX .

However XLC 12.1   does not support  the "-qvisibility=hidden"  setting 
currently set on AIX.
It was introduced with  XLC 13.1 . Christoph found some info about it here :

https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html

Setting it  only generates  hundreds  of warnings  in the build log , warnings 
look like this :
XlC12.1

bash-4.4$ xlC -qversion
IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)
Version: 12.01..0019

bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid 
options.

Compare to XLC13.1

bash-3.00$ xlC -qversion
IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07)
Version: 13.01..0008
bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc


So it is better to avoid  setting these flags when using xlc12.1   .
Please review :

Bug :

https://bugs.openjdk.java.net/browse/JDK-8202322

Change :

http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/


Best regards, Matthias

Re: RFR: 8202330: Add Unreferenced{FOS,FIS,RAF}ClosesFd to problem list

[Alan Bateman]

On 26/04/2018 16:41, Mikael Vidstedt wrote:

The java/io/*/Unreferenced{FOS,FIS,RAF}ClosesFd tests are failing quite frequently 
and should be added to the problem list until the issue (tracked by 
https://bugs.openjdk.java.net/browse/JDK-8202292 
) has been resolved:

Bug: https://bugs.openjdk.java.net/browse/JDK-8202330
Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8202330/webrev.00/open/webrev/ 



This looks okay to me.

-Alan

Re: [AIX] Fix codepage mappings in Java for IBM-943 and Big5

[Bhaktavatsal R Maram]

Hi Volker,

Thank you. I will address your review comments and send webrev for review.

- Bhaktavatsal Reddy 

  

-Volker Simonis  wrote: -
To: Bhaktavatsal R Maram 
From: Volker Simonis 
Date: 04/26/2018 09:12PM
Cc: Java Core Libs 
Subject: Re: [AIX] Fix codepage mappings in Java for IBM-943 and Big5

Hi Bhaktavatsal Reddy,

I've opened the following issue for this problem:

8202329: [AIX] Fix codepage mappings for IBM-943 and Big5
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8202329=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg=iQCg2Acve4LeG-Zymt7gpXuSgJLFbCFHsSVHCETqGt8=3KL9rSzXZgjLGz-ayIEaq94QK5rTY0PlEgewOjarNPE=

Looking at you fix, can you please replace the "#elif AIX" by "#ifdef
AIX" and the original "#else" by "#ifdef __solaris__". The original
else branch contains Solaris-only code anyway and it is an historical
omission that there are still a lot of places in the code where "not
Linux" implicitly means "Solaris", but that's often wrong.

Regards,
Volker


On Thu, Apr 26, 2018 at 4:02 PM, Bhaktavatsal R Maram
 wrote:
> Oops! Looks like there is problem with attachment (might be because I 
> attached .class file as well). I'm pasting the fix and test program here in 
> mail.
>
> Test Program:
>
> import java.nio.charset.*;
> class PrintDefaultCharset {
>  public static void main(String[] args) {
> System.out.println("LANG = "+System.getenv("LANG"));
> System.out.println("Default charset = 
> "+Charset.defaultCharset().name());
> System.out.println("file.encoding = 
> "+System.getProperty("file.encoding"));
> System.out.println("sun.jnu.encoding = 
> "+System.getProperty("sun.jnu.encoding"));
>  }
> }
>
>
> Fix:
>
> diff --git a/src/java.base/unix/native/libjava/java_props_md.c 
> b/src/java.base/unix/native/libjava/java_props_md.c
> --- a/src/java.base/unix/native/libjava/java_props_md.c
> +++ b/src/java.base/unix/native/libjava/java_props_md.c
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1998, 2018, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -297,6 +297,18 @@
>  if (strcmp(p, "EUC-JP") == 0) {
>  *std_encoding = "EUC-JP-LINUX";
>  }
> +#elif defined _AIX
> +if (strcmp(p, "big5") == 0) {
> +/* On AIX Traditional Chinese Big5 codeset is mapped to IBM-950 
> */
> +*std_encoding = "IBM-950";
> +} else if (strcmp(p, "IBM-943") == 0) {
> +/*
> + * On AIX, IBM-943 is mapped to IBM-943C in which symbol 'yen' 
> and
> + * 'overline' are replaced with 'backslash' and 'tilde' from 
> ASCII
> + * making first 96 code points same as ASCII.
> + */
> +*std_encoding = "IBM-943C";
> +}
>  #else
>  if (strcmp(p,"eucJP") == 0) {
>  /* For Solaris use customized vendor defined character
>
>
> Thanks,
> Bhaktavatsal Reddy
>
>
> -"core-libs-dev"  wrote: -
> To: "Java Core Libs" 
> From: "Bhaktavatsal R Maram"
> Sent by: "core-libs-dev"
> Date: 04/26/2018 07:26PM
> Subject: [AIX] Fix codepage mappings in Java for IBM-943 and Big5
>
> Hi All,
>
> This issue is continuation to bug 8201540 (Extend the set of supported 
> charsets in java.base on AIX) in which we have moved default charsets of most 
> of the locales supported by Operating System to java.base module thus 
> enabling OpenJDK on those locales for AIX platform.
>
> As part of that, charsets for locales Ja_JP (IBM-943) and Zh_TW (big5) also 
> have been moved. However, corresponding charsets mapped in Java is not 
> correct for them on AIX. Following are the details:
>
> 1. IBM-943 [1] for locale Ja_JP should be mapped to IBM-943C [2]
>
> Fundamental difference between IBM-943 and IBM-943C is that IBM-943C is ASCII 
> compatible which means code points 'yen' and 'overline' of IBM-943 is 
> replaced with 'backslash' and 'tilde' from ASCII character set.
>
>
> 2. Big5 for locale Zh_TW should be mapped to IBM-950 [3]
>
> I've attached simple test program to print the default charset along with fix 
> for this issue. When run test program (PrintDefaultCharset) with IBM JDK 8 
> (on AIX) for locales Ja_JP & Zh_TW, following is output.
>
> -bash-4.4$ LANG=Ja_JP ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset
> LANG = Ja_JP
> Default charset = x-IBM943C
> file.encoding = IBM-943C
> sun.jnu.encoding = IBM-943C
>
> -bash-4.4$ LANG=Zh_TW ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset
> LANG = Zh_TW
> Default charset = x-IBM950

Re: RFR: 8202330: Add Unreferenced{FOS, FIS, RAF}ClosesFd to problem list

[Brian Burkhalter]

Hi Mikael,

+1

Thanks,

Brian

On Apr 26, 2018, at 8:41 AM, Mikael Vidstedt  wrote:

> The java/io/*/Unreferenced{FOS,FIS,RAF}ClosesFd tests are failing quite 
> frequently and should be added to the problem list until the issue (tracked 
> byhttps://bugs.openjdk.java.net/browse/JDK-8202292)
>  has been resolved:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202330
> Webrev:http://cr.openjdk.java.net/~mikael/webrevs/8202330/webrev.00/open/webrev/

Re: [AIX] Fix codepage mappings in Java for IBM-943 and Big5

[Volker Simonis]

Hi Bhaktavatsal Reddy,

I've opened the following issue for this problem:

8202329: [AIX] Fix codepage mappings for IBM-943 and Big5
https://bugs.openjdk.java.net/browse/JDK-8202329

Looking at you fix, can you please replace the "#elif AIX" by "#ifdef
AIX" and the original "#else" by "#ifdef __solaris__". The original
else branch contains Solaris-only code anyway and it is an historical
omission that there are still a lot of places in the code where "not
Linux" implicitly means "Solaris", but that's often wrong.

Regards,
Volker


On Thu, Apr 26, 2018 at 4:02 PM, Bhaktavatsal R Maram
 wrote:
> Oops! Looks like there is problem with attachment (might be because I 
> attached .class file as well). I'm pasting the fix and test program here in 
> mail.
>
> Test Program:
>
> import java.nio.charset.*;
> class PrintDefaultCharset {
>  public static void main(String[] args) {
> System.out.println("LANG = "+System.getenv("LANG"));
> System.out.println("Default charset = 
> "+Charset.defaultCharset().name());
> System.out.println("file.encoding = 
> "+System.getProperty("file.encoding"));
> System.out.println("sun.jnu.encoding = 
> "+System.getProperty("sun.jnu.encoding"));
>  }
> }
>
>
> Fix:
>
> diff --git a/src/java.base/unix/native/libjava/java_props_md.c 
> b/src/java.base/unix/native/libjava/java_props_md.c
> --- a/src/java.base/unix/native/libjava/java_props_md.c
> +++ b/src/java.base/unix/native/libjava/java_props_md.c
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1998, 2018, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -297,6 +297,18 @@
>  if (strcmp(p, "EUC-JP") == 0) {
>  *std_encoding = "EUC-JP-LINUX";
>  }
> +#elif defined _AIX
> +if (strcmp(p, "big5") == 0) {
> +/* On AIX Traditional Chinese Big5 codeset is mapped to IBM-950 
> */
> +*std_encoding = "IBM-950";
> +} else if (strcmp(p, "IBM-943") == 0) {
> +/*
> + * On AIX, IBM-943 is mapped to IBM-943C in which symbol 'yen' 
> and
> + * 'overline' are replaced with 'backslash' and 'tilde' from 
> ASCII
> + * making first 96 code points same as ASCII.
> + */
> +*std_encoding = "IBM-943C";
> +}
>  #else
>  if (strcmp(p,"eucJP") == 0) {
>  /* For Solaris use customized vendor defined character
>
>
> Thanks,
> Bhaktavatsal Reddy
>
>
> -"core-libs-dev"  wrote: -
> To: "Java Core Libs" 
> From: "Bhaktavatsal R Maram"
> Sent by: "core-libs-dev"
> Date: 04/26/2018 07:26PM
> Subject: [AIX] Fix codepage mappings in Java for IBM-943 and Big5
>
> Hi All,
>
> This issue is continuation to bug 8201540 (Extend the set of supported 
> charsets in java.base on AIX) in which we have moved default charsets of most 
> of the locales supported by Operating System to java.base module thus 
> enabling OpenJDK on those locales for AIX platform.
>
> As part of that, charsets for locales Ja_JP (IBM-943) and Zh_TW (big5) also 
> have been moved. However, corresponding charsets mapped in Java is not 
> correct for them on AIX. Following are the details:
>
> 1. IBM-943 [1] for locale Ja_JP should be mapped to IBM-943C [2]
>
> Fundamental difference between IBM-943 and IBM-943C is that IBM-943C is ASCII 
> compatible which means code points 'yen' and 'overline' of IBM-943 is 
> replaced with 'backslash' and 'tilde' from ASCII character set.
>
>
> 2. Big5 for locale Zh_TW should be mapped to IBM-950 [3]
>
> I've attached simple test program to print the default charset along with fix 
> for this issue. When run test program (PrintDefaultCharset) with IBM JDK 8 
> (on AIX) for locales Ja_JP & Zh_TW, following is output.
>
> -bash-4.4$ LANG=Ja_JP ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset
> LANG = Ja_JP
> Default charset = x-IBM943C
> file.encoding = IBM-943C
> sun.jnu.encoding = IBM-943C
>
> -bash-4.4$ LANG=Zh_TW ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset
> LANG = Zh_TW
> Default charset = x-IBM950
> file.encoding = IBM-950
> sun.jnu.encoding = IBM-950
>
>
> Same test run with openJDK 11 gives following output
>
> -bash-4.4$ LANG=Ja_JP ~/jdk/bin/java PrintDefaultCharset
> LANG = Ja_JP
> Default charset = x-IBM943
> file.encoding = IBM-943
> sun.jnu.encoding = IBM-943
>
> -bash-4.4$ LANG=Zh_TW ~/jdk/bin/java PrintDefaultCharset
> LANG = Zh_TW
> Default charset = Big5
> file.encoding = big5
> sun.jnu.encoding = big5
>
> I will get webrev hosted in 
> 

RFR: 8202330: Add Unreferenced{FOS,FIS,RAF}ClosesFd to problem list

[Mikael Vidstedt]

The java/io/*/Unreferenced{FOS,FIS,RAF}ClosesFd tests are failing quite 
frequently and should be added to the problem list until the issue (tracked by 
https://bugs.openjdk.java.net/browse/JDK-8202292 
) has been resolved:

Bug: https://bugs.openjdk.java.net/browse/JDK-8202330
Webrev: 
http://cr.openjdk.java.net/~mikael/webrevs/8202330/webrev.00/open/webrev/ 


Cheers,
Mikael

Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Volker Simonis]

Hi Matthias,

after Bhaktavatsal Reddy's report about the problems with
"-qvisibility" with xlC 13 and taking into account that we can't test
this anyway because we don't currently have xlC 13
 on our machines I think it would be best to completely remove this
option for now on AIX. Once we get xlC 13 we can revisit the issue.

Thanks,
Volker


On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram
 wrote:
> Hi Matthias,
>
> At this point, I think we can remove the flag as you found that it is not 
> supported in XLC < 13. And with XLC 13, it require more work to use this flag.
>
> Thanks,
> Bhaktavatsal Reddy
>
>
>
> -"Baesken, Matthias"  wrote: -
> To: "Langer, Christoph" , 
> "'build-...@openjdk.java.net'" , 
> "ppc-aix-port-...@openjdk.java.net" , 
> "core-libs-dev@openjdk.java.net" 
> From: "Baesken, Matthias" 
> Date: 04/26/2018 08:23PM
> Cc: "Simonis, Volker" , Bhaktavatsal R Maram
> 
> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
> 12.1
>
>
>  Hello Christoph,   I think  all XLC versions  < 12.1   are unsupported  (and 
> probably not working anyway)  for the OpenJDK  build .
>  I am only aware   of  XLC  versions  12.1  and 13.1which  work / in case 
> of 13.1  “might” work   for OpenJDK compilation .
>  And for 12.1  I want to remove the flags  .
>
>  ( waiting for the feedback  of   Bhaktavatsal Reddy ,  in case he  prefers 
> it  I remove them for all xlC versions including 13.1 )
>
>  Best regards, Matthias
>
>
>
>
>
>
>  From: Langer, Christoph
>  Sent: Donnerstag, 26. April 2018 16:38
>  To: Baesken, Matthias ; 
> 'build-...@openjdk.java.net' ; 
> ppc-aix-port-...@openjdk.java.net; core-libs-dev@openjdk.java.net
>  Cc: Simonis, Volker 
>  Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
> 12.1
>
>  Hi Matthias,
>
>  to me the change in principal looks good.
>
>  I’m wondering if it is possible to do a comparison like xlc < 13 (e.g. 
> extract major number before the first dot, then compare numerically) – but 
> maybe it is too complicated and the current single version compare suits  our 
> needs ?
>
>  Best regards
>  Christoph
>
>
>
>
>  From: Baesken, Matthias
>  Sent: Donnerstag, 26. April 2018 16:14
>  To: 'build-...@openjdk.java.net' ; 
> ppc-aix-port-...@openjdk.java.net; core-libs-dev@openjdk.java.net
>  Cc: Langer, Christoph ; Simonis, Volker 
> 
>  Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1
>
>  Hello  ,  could you please review this small adjustment to  the symbol 
> visibility compilation settings on AIX ?
>  Currently  we use  XLC 12.1  to compile  JDK on AIX .
>
>  However XLC 12.1   does not support  the “-qvisibility=hidden”  setting 
> currently set on AIX.
>  It was introduced with  XLC 13.1 . Christoph found some info about it here :
>
>  
> https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html
>
>  Setting it  only generates  hundreds  of warnings  in the build log , 
> warnings look like this :
>  XlC12.1
>
>  bash-4.4$ xlC -qversion
>  IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)
>  Version: 12.01..0019
>
>  bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
>  1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of 
> valid options.
>
>  Compare to XLC13.1
>
>  bash-3.00$ xlC -qversion
>  IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07)
>  Version: 13.01..0008
>  bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
>  bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
>
>
>  So it is better to avoid  setting these flags when using xlc12.1   .
>  Please review :
>
>  Bug :
>
>  https://bugs.openjdk.java.net/browse/JDK-8202322
>
>  Change :
>
>  http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/
>
>
>  Best regards, Matthias
>
>
>
>

Re: RFR: 8202324: Avoid loading FileInput-/OutputStream$AltFinalizer

[Claes Redestad]

On 2018-04-26 15:49, Alan Bateman wrote:


Webrev: http://cr.openjdk.java.net/~redestad/8202324/open.00/

This looks okay as the AltFinalizer classes are only needed when code 
is extending FIS or FOS.


Thanks, Alan!

/Claes

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Bhaktavatsal R Maram]

Hi Matthias,

At this point, I think we can remove the flag as you found that it is not 
supported in XLC < 13. And with XLC 13, it require more work to use this flag.

Thanks,
Bhaktavatsal Reddy

  

-"Baesken, Matthias"  wrote: -
To: "Langer, Christoph" , 
"'build-...@openjdk.java.net'" , 
"ppc-aix-port-...@openjdk.java.net" , 
"core-libs-dev@openjdk.java.net" 
From: "Baesken, Matthias" 
Date: 04/26/2018 08:23PM
Cc: "Simonis, Volker" , Bhaktavatsal R Maram

Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

   
 Hello Christoph,   I think  all XLC versions  < 12.1   are unsupported  (and 
probably not working anyway)  for the OpenJDK  build .
 I am only aware   of  XLC  versions  12.1  and 13.1which  work / in case 
of 13.1  “might” work   for OpenJDK compilation .
 And for 12.1  I want to remove the flags  .
  
 ( waiting for the feedback  of   Bhaktavatsal Reddy ,  in case he  prefers it  
I remove them for all xlC versions including 13.1 )
  
 Best regards, Matthias
  
  
  
 
 
 
 From: Langer, Christoph 
 Sent: Donnerstag, 26. April 2018 16:38
 To: Baesken, Matthias ; 'build-...@openjdk.java.net' 
; ppc-aix-port-...@openjdk.java.net; 
core-libs-dev@openjdk.java.net
 Cc: Simonis, Volker 
 Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
12.1

 Hi Matthias,
  
 to me the change in principal looks good.
  
 I’m wondering if it is possible to do a comparison like xlc < 13 (e.g. extract 
major number before the first dot, then compare numerically) – but maybe it is 
too complicated and the current single version compare suits  our needs ?
  
 Best regards
 Christoph
  
  
 
 
 From: Baesken, Matthias 
 Sent: Donnerstag, 26. April 2018 16:14
 To: 'build-...@openjdk.java.net' ; 
ppc-aix-port-...@openjdk.java.net; core-libs-dev@openjdk.java.net
 Cc: Langer, Christoph ; Simonis, Volker 

 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

 Hello  ,  could you please review this small adjustment to  the symbol 
visibility compilation settings on AIX ?
 Currently  we use  XLC 12.1  to compile  JDK on AIX .
  
 However XLC 12.1   does not support  the “-qvisibility=hidden”  setting 
currently set on AIX.
 It was introduced with  XLC 13.1 . Christoph found some info about it here :
  
 
https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html
  
 Setting it  only generates  hundreds  of warnings  in the build log , warnings 
look like this :
 XlC12.1
  
 bash-4.4$ xlC -qversion
 IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)
 Version: 12.01..0019
  
 bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of 
valid options.
  
 Compare to XLC13.1
  
 bash-3.00$ xlC -qversion
 IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07)
 Version: 13.01..0008
 bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
 bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
  
  
 So it is better to avoid  setting these flags when using xlc12.1   .
 Please review :
  
 Bug :
  
 https://bugs.openjdk.java.net/browse/JDK-8202322
  
 Change :
  
 http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/
  
  
 Best regards, Matthias
  
  
  

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Baesken, Matthias]

Hello Christoph,   I think  all XLC versions  < 12.1   are unsupported  (and 
probably not working anyway)  for the OpenJDK  build .

I am only aware   of  XLC  versions  12.1  and 13.1which  work / in case of 
13.1  "might" work   for OpenJDK compilation .

And for 12.1  I want to remove the flags  .



( waiting for the feedback  of  Bhaktavatsal Reddy ,  in case he  prefers it  I 
remove them for all xlC versions including 13.1 )

Best regards, Matthias



From: Langer, Christoph
Sent: Donnerstag, 26. April 2018 16:38
To: Baesken, Matthias ; 'build-...@openjdk.java.net' 
; ppc-aix-port-...@openjdk.java.net; 
core-libs-dev@openjdk.java.net
Cc: Simonis, Volker 
Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

Hi Matthias,

to me the change in principal looks good.

I'm wondering if it is possible to do a comparison like xlc < 13 (e.g. extract 
major number before the first dot, then compare numerically) - but maybe it is 
too complicated and the current single version compare suits our needs ?

Best regards
Christoph

From: Baesken, Matthias
Sent: Donnerstag, 26. April 2018 16:14
To: 'build-...@openjdk.java.net' 
>; 
ppc-aix-port-...@openjdk.java.net; 
core-libs-dev@openjdk.java.net
Cc: Langer, Christoph 
>; Simonis, Volker 
>
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

Hello  ,  could you please review this small adjustment to  the symbol 
visibility compilation settings on AIX ?
Currently  we use  XLC 12.1  to compile  JDK on AIX .

However XLC 12.1   does not support  the "-qvisibility=hidden"  setting 
currently set on AIX.
It was introduced with  XLC 13.1 . Christoph found some info about it here :

https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html

Setting it  only generates  hundreds  of warnings  in the build log , warnings 
look like this :
XlC12.1

bash-4.4$ xlC -qversion
IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)
Version: 12.01..0019

bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid 
options.

Compare to XLC13.1

bash-3.00$ xlC -qversion
IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07)
Version: 13.01..0008
bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc


So it is better to avoid  setting these flags when using xlc12.1   .
Please review :

Bug :

https://bugs.openjdk.java.net/browse/JDK-8202322

Change :

http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/


Best regards, Matthias

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Langer, Christoph]

Hi Matthias,

to me the change in principal looks good.

I'm wondering if it is possible to do a comparison like xlc < 13 (e.g. extract 
major number before the first dot, then compare numerically) - but maybe it is 
too complicated and the current single version compare suits our needs ?

Best regards
Christoph

From: Baesken, Matthias
Sent: Donnerstag, 26. April 2018 16:14
To: 'build-...@openjdk.java.net' ; 
ppc-aix-port-...@openjdk.java.net; core-libs-dev@openjdk.java.net
Cc: Langer, Christoph ; Simonis, Volker 

Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

Hello  ,  could you please review this small adjustment to  the symbol 
visibility compilation settings on AIX ?
Currently  we use  XLC 12.1  to compile  JDK on AIX .

However XLC 12.1   does not support  the "-qvisibility=hidden"  setting 
currently set on AIX.
It was introduced with  XLC 13.1 . Christoph found some info about it here :

https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html

Setting it  only generates  hundreds  of warnings  in the build log , warnings 
look like this :
XlC12.1

bash-4.4$ xlC -qversion
IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)
Version: 12.01..0019

bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid 
options.

Compare to XLC13.1

bash-3.00$ xlC -qversion
IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07)
Version: 13.01..0008
bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc


So it is better to avoid  setting these flags when using xlc12.1   .
Please review :

Bug :

https://bugs.openjdk.java.net/browse/JDK-8202322

Change :

http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/


Best regards, Matthias

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Baesken, Matthias]

> Its right in time. I am facing "Undefined Symbol" errors with XLC 13.1 due to
> "-qvisibility=hidden" which hides all symbols by default. I workaround that by
> removing this flag

Hello,   so  it seems  that I  better  remove   the  "-qvisibility="  
completely  for xlc  (and not only for xlc12.1)   ?

(we currently  compile only  with XLC 12.1  ,   there might be more issues  
with 13.1 )


Best regards, Matthias



> -Original Message-
> From: Bhaktavatsal R Maram [mailto:bhama...@in.ibm.com]
> Sent: Donnerstag, 26. April 2018 16:32
> To: Baesken, Matthias 
> Cc: 'build-...@openjdk.java.net' ; ppc-aix-
> port-...@openjdk.java.net; core-libs-dev@openjdk.java.net; Simonis,
> Volker 
> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
> 12.1
> 
> Hi Matthias,
> 
> Its right in time. I am facing "Undefined Symbol" errors with XLC 13.1 due to
> "-qvisibility=hidden" which hides all symbols by default. I workaround that by
> removing this flag
> 
> -bash-4.4$ xlC -qversion
> IBM XL C/C++ for AIX, V13.1.3 (5725-C72, 5765-J07)
> Version: 13.01.0003.
> 
> Looks like there are many function declarations that require changes to make
> function visible.
> 
> Thanks,
> Bhaktavatsal Reddy
> 
> 
> 
> -"core-libs-dev"  wrote: -
> To: "'build-...@openjdk.java.net'" , "ppc-
> aix-port-...@openjdk.java.net" ,
> "core-libs-dev@openjdk.java.net" 
> From: "Baesken, Matthias"
> Sent by: "core-libs-dev"
> Date: 04/26/2018 07:45PM
> Cc: "Simonis, Volker" 
> Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1
> 
> Hello  ,  could you please review this small adjustment to  the symbol 
> visibility
> compilation settings on AIX ?
> Currently  we use  XLC 12.1  to compile  JDK on AIX .
> 
> However XLC 12.1   does not support  the "-qvisibility=hidden"  setting
> currently set on AIX.
> It was introduced with  XLC 13.1 . Christoph found some info about it here :
> 
> https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-
> part2/index.html
> 
> Setting it  only generates  hundreds  of warnings  in the build log , warnings
> look like this :
> XlC12.1
> 
> bash-4.4$ xlC -qversion
> IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)
> Version: 12.01..0019
> 
> bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
> 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of 
> valid
> options.
> 
> Compare to XLC13.1
> 
> bash-3.00$ xlC -qversion
> IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07)
> Version: 13.01..0008
> bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
> bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
> 
> 
> So it is better to avoid  setting these flags when using xlc12.1   .
> Please review :
> 
> Bug :
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__bugs.openjdk.java.net_browse_JDK-
> 2D8202322=DwIFAg=jf_iaSHvJObTbx-
> siA1ZOg=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg
> =F6_aATE7bsRWZG5lPZhJUESHNGqST5MNbkULllIH8l4=M4IJ-
> YdB3dfN7lj0DEWozQbipDXmgKtSu3pEyMcJF_E=
> 
> Change :
> 
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__cr.openjdk.java.net_-
> 7Embaesken_webrevs_8202322_=DwIFAg=jf_iaSHvJObTbx-
> siA1ZOg=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg
> =F6_aATE7bsRWZG5lPZhJUESHNGqST5MNbkULllIH8l4=gb0OP9fQTAWWJb
> BZDK6L_0gTKf1pwna8aXaYr_uVv8Q=
> 
> 
> Best regards, Matthias
> 
> 

Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Bhaktavatsal R Maram]

Hi Matthias,

Its right in time. I am facing "Undefined Symbol" errors with XLC 13.1 due to 
"-qvisibility=hidden" which hides all symbols by default. I workaround that by 
removing this flag

-bash-4.4$ xlC -qversion
IBM XL C/C++ for AIX, V13.1.3 (5725-C72, 5765-J07)
Version: 13.01.0003.

Looks like there are many function declarations that require changes to make 
function visible.

Thanks,
Bhaktavatsal Reddy

  

-"core-libs-dev"  wrote: -
To: "'build-...@openjdk.java.net'" , 
"ppc-aix-port-...@openjdk.java.net" , 
"core-libs-dev@openjdk.java.net" 
From: "Baesken, Matthias" 
Sent by: "core-libs-dev" 
Date: 04/26/2018 07:45PM
Cc: "Simonis, Volker" 
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

Hello  ,  could you please review this small adjustment to  the symbol 
visibility compilation settings on AIX ?
Currently  we use  XLC 12.1  to compile  JDK on AIX .

However XLC 12.1   does not support  the "-qvisibility=hidden"  setting 
currently set on AIX.
It was introduced with  XLC 13.1 . Christoph found some info about it here :

https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html

Setting it  only generates  hundreds  of warnings  in the build log , warnings 
look like this :
XlC12.1

bash-4.4$ xlC -qversion
IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)
Version: 12.01..0019

bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid 
options.

Compare to XLC13.1

bash-3.00$ xlC -qversion
IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07)
Version: 13.01..0008
bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc


So it is better to avoid  setting these flags when using xlc12.1   .
Please review :

Bug :

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8202322=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg=F6_aATE7bsRWZG5lPZhJUESHNGqST5MNbkULllIH8l4=M4IJ-YdB3dfN7lj0DEWozQbipDXmgKtSu3pEyMcJF_E=

Change :

https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Embaesken_webrevs_8202322_=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg=F6_aATE7bsRWZG5lPZhJUESHNGqST5MNbkULllIH8l4=gb0OP9fQTAWWJbBZDK6L_0gTKf1pwna8aXaYr_uVv8Q=


Best regards, Matthias

Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Thomas Stüfe]

Hi Matthias,

I would prefer a numerical comparison to version < 13. Otherwise the
code looks like you want to just exclude 12.1 for some reason when in
reality you want to omit the flag for any compiler older than xlc 13.

Best Regards, Thomas


On Thu, Apr 26, 2018 at 4:13 PM, Baesken, Matthias
 wrote:
> Hello  ,  could you please review this small adjustment to  the symbol 
> visibility compilation settings on AIX ?
> Currently  we use  XLC 12.1  to compile  JDK on AIX .
>
> However XLC 12.1   does not support  the "-qvisibility=hidden"  setting 
> currently set on AIX.
> It was introduced with  XLC 13.1 . Christoph found some info about it here :
>
> https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html
>
> Setting it  only generates  hundreds  of warnings  in the build log , 
> warnings look like this :
> XlC12.1
>
> bash-4.4$ xlC -qversion
> IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)
> Version: 12.01..0019
>
> bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
> 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of 
> valid options.
>
> Compare to XLC13.1
>
> bash-3.00$ xlC -qversion
> IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07)
> Version: 13.01..0008
> bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
> bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
>
>
> So it is better to avoid  setting these flags when using xlc12.1   .
> Please review :
>
> Bug :
>
> https://bugs.openjdk.java.net/browse/JDK-8202322
>
> Change :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/
>
>
> Best regards, Matthias
>
>

Review Request JDK-8201793: (ref) Reference object should not support cloning

[mandy chung]

The semantics of cloning a Reference object is not clearly defined. In 
addition, it is questionable whether it can be meaningfully supported in 
particular with concurrent reference processing.


The reachability state of a Reference object may change during GC 
reference processing. The referent may have been cleared when it reaches 
its reachability state. In addition, it may be enqueued or pending for 
enqueuing. Cloning a Reference object with a referent that is 
unreachable but not yet cleared might mean to resurrect the referent. A 
cloned enqueued Reference object will never be enqueued.  A Reference 
object cannot be meaningfully cloned.


We propose Reference::clone to throw CloneNotSupportedException.  To 
clone a Reference object, it should create a new instance via its 
constructor.


CSR: https://bugs.openjdk.java.net/browse/JDK-8202260

Webrev:
http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8201793/webrev.00/

Mandy

RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Baesken, Matthias]

Hello  ,  could you please review this small adjustment to  the symbol 
visibility compilation settings on AIX ?
Currently  we use  XLC 12.1  to compile  JDK on AIX .

However XLC 12.1   does not support  the "-qvisibility=hidden"  setting 
currently set on AIX.
It was introduced with  XLC 13.1 . Christoph found some info about it here :

https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html

Setting it  only generates  hundreds  of warnings  in the build log , warnings 
look like this :
XlC12.1

bash-4.4$ xlC -qversion
IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)
Version: 12.01..0019

bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc
1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid 
options.

Compare to XLC13.1

bash-3.00$ xlC -qversion
IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07)
Version: 13.01..0008
bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc
bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc


So it is better to avoid  setting these flags when using xlc12.1   .
Please review :

Bug :

https://bugs.openjdk.java.net/browse/JDK-8202322

Change :

http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/


Best regards, Matthias

Re: [AIX] Fix codepage mappings in Java for IBM-943 and Big5

[Bhaktavatsal R Maram]

Oops! Looks like there is problem with attachment (might be because I attached 
.class file as well). I'm pasting the fix and test program here in mail.

Test Program:

import java.nio.charset.*;
class PrintDefaultCharset {
 public static void main(String[] args) {
System.out.println("LANG = "+System.getenv("LANG"));
System.out.println("Default charset = 
"+Charset.defaultCharset().name());
System.out.println("file.encoding = 
"+System.getProperty("file.encoding"));
System.out.println("sun.jnu.encoding = 
"+System.getProperty("sun.jnu.encoding"));
 }
}


Fix:

diff --git a/src/java.base/unix/native/libjava/java_props_md.c 
b/src/java.base/unix/native/libjava/java_props_md.c
--- a/src/java.base/unix/native/libjava/java_props_md.c
+++ b/src/java.base/unix/native/libjava/java_props_md.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1998, 2018, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -297,6 +297,18 @@
 if (strcmp(p, "EUC-JP") == 0) {
 *std_encoding = "EUC-JP-LINUX";
 }
+#elif defined _AIX
+if (strcmp(p, "big5") == 0) {
+/* On AIX Traditional Chinese Big5 codeset is mapped to IBM-950 */
+*std_encoding = "IBM-950";
+} else if (strcmp(p, "IBM-943") == 0) {
+/*
+ * On AIX, IBM-943 is mapped to IBM-943C in which symbol 'yen' and
+ * 'overline' are replaced with 'backslash' and 'tilde' from ASCII
+ * making first 96 code points same as ASCII.
+ */
+*std_encoding = "IBM-943C";
+}
 #else
 if (strcmp(p,"eucJP") == 0) {
 /* For Solaris use customized vendor defined character

 
Thanks,
Bhaktavatsal Reddy
  

-"core-libs-dev"  wrote: -
To: "Java Core Libs" 
From: "Bhaktavatsal R Maram" 
Sent by: "core-libs-dev" 
Date: 04/26/2018 07:26PM
Subject: [AIX] Fix codepage mappings in Java for IBM-943 and Big5

Hi All,

This issue is continuation to bug 8201540 (Extend the set of supported charsets 
in java.base on AIX) in which we have moved default charsets of most of the 
locales supported by Operating System to java.base module thus enabling OpenJDK 
on those locales for AIX platform. 

As part of that, charsets for locales Ja_JP (IBM-943) and Zh_TW (big5) also 
have been moved. However, corresponding charsets mapped in Java is not correct 
for them on AIX. Following are the details:

1. IBM-943 [1] for locale Ja_JP should be mapped to IBM-943C [2]

Fundamental difference between IBM-943 and IBM-943C is that IBM-943C is ASCII 
compatible which means code points 'yen' and 'overline' of IBM-943 is replaced 
with 'backslash' and 'tilde' from ASCII character set.


2. Big5 for locale Zh_TW should be mapped to IBM-950 [3]

I've attached simple test program to print the default charset along with fix 
for this issue. When run test program (PrintDefaultCharset) with IBM JDK 8 (on 
AIX) for locales Ja_JP & Zh_TW, following is output.

-bash-4.4$ LANG=Ja_JP ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset 
LANG = Ja_JP
Default charset = x-IBM943C
file.encoding = IBM-943C
sun.jnu.encoding = IBM-943C

-bash-4.4$ LANG=Zh_TW ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset
LANG = Zh_TW
Default charset = x-IBM950
file.encoding = IBM-950
sun.jnu.encoding = IBM-950


Same test run with openJDK 11 gives following output

-bash-4.4$ LANG=Ja_JP ~/jdk/bin/java PrintDefaultCharset
LANG = Ja_JP
Default charset = x-IBM943
file.encoding = IBM-943
sun.jnu.encoding = IBM-943

-bash-4.4$ LANG=Zh_TW ~/jdk/bin/java PrintDefaultCharset
LANG = Zh_TW
Default charset = Big5
file.encoding = big5
sun.jnu.encoding = big5

I will get webrev hosted in 
https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg=Prdd2GWj8c4aCa1qPr65xklNyDyu64w_6X7qkNaI-D8=8C1bILMg6JLJtbL0KLRPfU0MkIPkAmq_IlJgdTfpjdI=
 for this change and send it for review once JIRA bug is created.

[1] 
https://urldefense.proofpoint.com/v2/url?u=http-3A__demo.icu-2Dproject.org_icu-2Dbin_convexp-3Fconv-3Dibm-2D943-5FP130-2D1999-26s-3DJAVA=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg=Prdd2GWj8c4aCa1qPr65xklNyDyu64w_6X7qkNaI-D8=RJOiyJTR1jkgxxnRZu5JL97irAnHo1M4wMp7x21dgvs=
[2] 
https://urldefense.proofpoint.com/v2/url?u=http-3A__demo.icu-2Dproject.org_icu-2Dbin_convexp-3Fconv-3Dibm-2D943-5FP15A-2D2003-26s-3DALL=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg=Prdd2GWj8c4aCa1qPr65xklNyDyu64w_6X7qkNaI-D8=gXshfq2f9yed1iEYTdt57Lk0vvHXztqgUzOLQ64h8Vo=
[3] 
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.nlsgdrf/big5.htm

[AIX] Fix codepage mappings in Java for IBM-943 and Big5

[Bhaktavatsal R Maram]

Hi All,

This issue is continuation to bug 8201540 (Extend the set of supported charsets 
in java.base on AIX) in which we have moved default charsets of most of the 
locales supported by Operating System to java.base module thus enabling OpenJDK 
on those locales for AIX platform. 

As part of that, charsets for locales Ja_JP (IBM-943) and Zh_TW (big5) also 
have been moved. However, corresponding charsets mapped in Java is not correct 
for them on AIX. Following are the details:

1. IBM-943 [1] for locale Ja_JP should be mapped to IBM-943C [2]

Fundamental difference between IBM-943 and IBM-943C is that IBM-943C is ASCII 
compatible which means code points 'yen' and 'overline' of IBM-943 is replaced 
with 'backslash' and 'tilde' from ASCII character set.


2. Big5 for locale Zh_TW should be mapped to IBM-950 [3]

I've attached simple test program to print the default charset along with fix 
for this issue. When run test program (PrintDefaultCharset) with IBM JDK 8 (on 
AIX) for locales Ja_JP & Zh_TW, following is output.

-bash-4.4$ LANG=Ja_JP ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset 
LANG = Ja_JP
Default charset = x-IBM943C
file.encoding = IBM-943C
sun.jnu.encoding = IBM-943C

-bash-4.4$ LANG=Zh_TW ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset
LANG = Zh_TW
Default charset = x-IBM950
file.encoding = IBM-950
sun.jnu.encoding = IBM-950


Same test run with openJDK 11 gives following output

-bash-4.4$ LANG=Ja_JP ~/jdk/bin/java PrintDefaultCharset
LANG = Ja_JP
Default charset = x-IBM943
file.encoding = IBM-943
sun.jnu.encoding = IBM-943

-bash-4.4$ LANG=Zh_TW ~/jdk/bin/java PrintDefaultCharset
LANG = Zh_TW
Default charset = Big5
file.encoding = big5
sun.jnu.encoding = big5

I will get webrev hosted in http://cr.openjdk.java.net for this change and send 
it for review once JIRA bug is created.

[1] http://demo.icu-project.org/icu-bin/convexp?conv=ibm-943_P130-1999=JAVA
[2] http://demo.icu-project.org/icu-bin/convexp?conv=ibm-943_P15A-2003=ALL
[3] 
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.nlsgdrf/big5.htm


Thanks,
Bhaktavatsal Reddy

Re: RFR: 8202324: Avoid loading FileInput-/OutputStream$AltFinalizer

[Alan Bateman]

On 26/04/2018 14:30, Claes Redestad wrote:

Hi,

we can avoid eagerly loading the FileInput-/OutputStream$AltFinalizer 
classes on normal use, which is a small startup win.


Webrev: http://cr.openjdk.java.net/~redestad/8202324/open.00/

Bug: https://bugs.openjdk.java.net/browse/JDK-8202324
This looks okay as the AltFinalizer classes are only needed when code is 
extending FIS or FOS.


-Alan.

RFR: 8202324: Avoid loading FileInput-/OutputStream$AltFinalizer

[Claes Redestad]

Hi,

we can avoid eagerly loading the FileInput-/OutputStream$AltFinalizer 
classes on normal use, which is a small startup win.


Webrev: http://cr.openjdk.java.net/~redestad/8202324/open.00/

Bug: https://bugs.openjdk.java.net/browse/JDK-8202324

Thanks!

/Claes

Re: 8202284: FileChannel and FileOutpuStream variants of AtomicAppend should pass silently on macOS >= 10.13

[Chris Hegarty]

> On 25 Apr 2018, at 23:11, Brian Burkhalter  
> wrote:
> 
> Issue:https://bugs.openjdk.java.net/browse/JDK-8202284
> Patch:http://cr.openjdk.java.net/~bpb/8202284/webrev.00/

I think this looks good Brian.

> On 26 Apr 2018, at 01:09, Brian Burkhalter  
> wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8202290 to track this problem.

I agree with filing a new issue to track the underlying bug,
rather than attempting to re-open an already resolved one.

-Chris.

Re: RFR: JDK-8202105: jshell tool: on exiting, terminal echo is disabled

[Jan Lahoda]

On 25.4.2018 22:59, Xueming Shen wrote:

On 04/25/2018 01:39 PM, Jan Lahoda wrote:

So, if I understand correctly, it would be:
boolean flipEcho;
and the readPassword would do something like:
if (echo0() != false) {


if (echo0()) { ...


flipEcho = true;
echo(false);
}

if (flipEcho) { //this would also be in the shutdown hook
 echo(!echo0());
}


if (flipEcho) {
 echo(true);
 flipEcho = false;
}
?


Hmm, right. It start to look a lot like the original code, with the 
exception that the flag is also checked inside readPassword:

http://cr.openjdk.java.net/~jlahoda/8202105/webrev.01/

(This also makes the shutdown hook registration lazy.)

Jan





I guess I can do that (the variant with two boolean feels to me
slightly easier to understand and a tiny bit more robust, but this
flip boolean variant is doable as well).

Thanks,
Jan

On 25.4.2018 21:07, Martin Buchholz wrote:

I keep hoping for something simpler.

Is it possible to have more than one Console object?  Looks like NO.
Assuming no, then you simply need one static flag

boolean restoreEcho;

(it could also be an instance field of Console - that would be slightly
more principled)

In readPassword you check current value of echo and set restoreEcho
if it
was changed.  Shutdown hook also checks the same restoreEcho.

For bonus points, only create the shutdown hook the first time
readPassword
is called with echo on to appease the Emacs shell users with pitchforks.

On Wed, Apr 25, 2018 at 9:34 AM, Xueming Shen 
wrote:


On 4/25/18, 9:02 AM, Martin Buchholz wrote:

It would be more correct I think for Console to track if there is a
pending readPassword in progress and try to restore echo on exit
only if
so.  But a little annoying to implement (need an additional boolean?)


I think that is what Jan proposed "to add restoredEchoOnShutdown =
true",
and I'm fine
with that. I'm just a little confused why jshell invokes
System.console()
if it handles all "raw"
terminal stuff itself.


On Wed, Apr 25, 2018 at 8:52 AM, Xueming Shen 
wrote:



Hi Jan,

I saw System.console() returns null inside jshell ... but it seems
there
are 2 vms.
I would assume jshell  itself sets the terminal to raw and then call
System.console()?
for example an alternative for this issue is to ask jshell's impl
to call
System.console()
before going into raw mode? No, I'm not saying the proposed one is
not a
good one,
just wanted to make sure I understand the situation correctly.

Thanks,
Sherman



On 4/25/18, 4:50 AM, Jan Lahoda wrote:


Hi,

Under:
https://bugs.openjdk.java.net/browse/JDK-8194750

j.i.Console was changed to capture the state of the terminal echo at
creation time, and to restore it on shutdown.

That is problematic at least in jshell, where the terminal is
already in
the raw mode when j.i.Console is created, and so "echo disabled" is
recorded there. So even though jshell itself sets the terminal
into the
original mode when it terminates, the shutdown hook in
j.i.Console, which
is run later, sets the echo to off even if it was enabled before
the VM
started.

My understanding is that the shutdown hook is only needed in case
the VM
goes down while readPassword is running. So I tried to change the
shutdown
hook to only work while readPassword is running.

Bug: https://bugs.openjdk.java.net/browse/JDK-8202105
Webrev: http://cr.openjdk.java.net/~jlahoda/8202105/webrev.00/

What do you think?

Thanks,
 Jan

Re: [PATCH] Prefer TMPDIR over hard coded /tmp

[Robert Stupp]

Right, it's come a few times. In principle it seems reasonable but it 
will likely have a tail of issues. One concern is that it will cause 
issues with the attach mechanism as that depends on the tool side 
knowing the target VM's tmp dir. There's also the transition issue 
where old JDKs will be using /tmp, new JDKs using whatever TMPDIR is 
set too. This is one of these issues where most of the work will be 
shaking out the knock on impact (that will be needed for the CSR and 
release note at least).


I'm not sure, whether I understand the concern about the attach 
mechanism, as that seems to use the directory returned by 
PlatformSupport->VMSupport.getVMTemporaryDirectory->JVM_GetTemporaryDirectory->os::get_temp_directory, 
which returns the hard coded "/tmp" for all Unix platforms (except 
MacOS). (No intention to change this.)


The concern about backward compatibility (app using a JVM with hard 
coded /tmp plus a JVM using TMPDIR) is absolutely correct. I'm just not 
sure whether that's actually (or usually) an issue for /tmp specifically 
(at least on Linux, 
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.html). Well, at 
least if people actually use /tmp as it's supposed to be used, since 
/tmp could perfectly be a volatile filesystem, but it's actually on 
persistent storage, probably due to "misuse".


What I'm currently thinking of is, whether a JVM flag (-XX:+PreferTMPDIR 
or so, defaults to false) could be a compromise that preserves the 
current behavior and prevents issues with existing applications but 
gives people the option to use TMPDIR for java.io.tmpdir, if they want 
to. Using TMPDIR for java.io.tmpdir is mostly useful for building and 
testing code - i.e. having an easier way to use different locations for 
java.io.tmpdir instead of, for example, digging through build files and 
inspecting command lines to check, whether surefire/junit/testng/JMH 
passed the correct java.io.tmpdir properly to a spawned, maybe short 
lived, child JVMs. WDYT?


Robert

--
Robert Stupp
@snazy

Re: [PATCH] Prefer TMPDIR over hard coded /tmp

[Alan Bateman]

On 26/04/2018 01:45, Brian Burkhalter wrote:

On Apr 25, 2018, at 5:38 PM, Brian Burkhalter  
wrote:


The attached patch changed the behavior to use the content of the environment 
variable TMPDIR, if present. Note that this does not change where the hsperf* 
folders are created.

The source change looks OK to me aside from the copyright year and that in the 
second line here

Note that I am only saying that the patch looks OK, not that we want to use it. 
There have been a number of issues filed in this area over time, for example 
https://bugs.openjdk.java.net/browse/JDK-6205979. There are arguments against 
this change.

Right, it's come a few times. In principle it seems reasonable but it 
will likely have a tail of issues. One concern is that it will cause 
issues with the attach mechanism as that depends on the tool side 
knowing the target VM's tmp dir. There's also the transition issue where 
old JDKs will be using /tmp, new JDKs using whatever TMPDIR is set too. 
This is one of these issues where most of the work will be shaking out 
the knock on impact (that will be needed for the CSR and release note at 
least).


-Alan