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

[Thomas Stüfe]

Hi Christoph

On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph
 wrote:
> Hi Thomas,
>
> Look at this blog: 
> https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html
>
> if I understand it correctly, the xlc 12 default behavior should be like what 
> we'd expect from -qvisibility=hidden.
>

Where in this article do you read this?

..Thomas

> Best regards
> Christoph
>
>> -Original Message-
>> From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf Of
>> Thomas Stüfe
>> Sent: Freitag, 27. April 2018 06:55
>> To: Volker Simonis ; Baesken, Matthias
>> 
>> Cc: Simonis, Volker ; ppc-aix-port-
>> d...@openjdk.java.net; core-libs-...@openjdk.java.net; build-
>> d...@openjdk.java.net
>> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
>> 12.1
>>
>> 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-
>> d...@openjdk.java.net'" , "ppc-aix-port-
>> d...@openjdk.java.net" , "core-libs-
>> d...@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-
>> d...@openjdk.java.net' ; ppc-aix-port-
>> d...@openjdk.java.net; core-libs-...@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-dev@openjdk.java.net' ; ppc-
>> aix-port-...@openjdk.java.net; core-libs-...@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 -qve

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

[Langer, Christoph]

Hi Thomas,

let me cite one section from the article:

--

Visibility attribute and backward compatibility on AIX

As we know from the previous article, on AIX, symbols are not visible by 
default unless we export them at the linking stage, either manually or with the 
help of CreateExportList. However, on Linux, symbols are, by default, with 
export (namely default) visibility. This brings a gap between the AIX 
visibility attribute and the GNU visibility attribute. To be backward 
compatible, on AIX, XL C/C++ would not set all the symbols to be exported like 
Linux. It might consider symbol without any visibility setting to be an 
unspecific visibility, which aligns with an old AIX implementation. For such 
symbols, AIX compiler, linker, and related tools would handle it as before. 
However, unspecific visibility does not mean that the symbol is internal or 
invisible at all. It is just a visibility that is specially designed to keep 
the compatibility.

...

--

It says in the first sentence: " As we know from the previous article, on AIX, 
symbols are not visible by default unless we export them at the linking stage, 
either manually or with the help of CreateExportList". I guess that is why I 
was under the impression that with xlc12 symbols would not be visible...

Best regards
Christoph

> -Original Message-
> From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
> Sent: Freitag, 27. April 2018 09:21
> To: Langer, Christoph 
> Cc: Volker Simonis ; Baesken, Matthias
> ; Simonis, Volker ;
> ppc-aix-port-...@openjdk.java.net; core-libs-...@openjdk.java.net; build-
> d...@openjdk.java.net
> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
> 12.1
> 
> Hi Christoph
> 
> On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph
>  wrote:
> > Hi Thomas,
> >
> > Look at this blog: https://www.ibm.com/developerworks/aix/library/au-
> aix-symbol-visibility-part2/index.html
> >
> > if I understand it correctly, the xlc 12 default behavior should be like 
> > what
> we'd expect from -qvisibility=hidden.
> >
> 
> Where in this article do you read this?
> 
> ..Thomas
> 
> > Best regards
> > Christoph
> >
> >> -Original Message-
> >> From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf
> Of
> >> Thomas Stüfe
> >> Sent: Freitag, 27. April 2018 06:55
> >> To: Volker Simonis ; Baesken, Matthias
> >> 
> >> Cc: Simonis, Volker ; ppc-aix-port-
> >> d...@openjdk.java.net; core-libs-...@openjdk.java.net; build-
> >> d...@openjdk.java.net
> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc
> 12.1
> >>
> >> 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-
> >> d...@openjdk.java.net'" , "ppc-aix-port-
> >> d...@openjdk.java.net" , "core-
> libs-
> >> d...@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, 

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

[Thomas Stüfe]

On Fri, Apr 27, 2018 at 9:27 AM, Langer, Christoph
 wrote:
> Hi Thomas,
>
> let me cite one section from the article:
>
> --
>
> Visibility attribute and backward compatibility on AIX
>
> As we know from the previous article, on AIX, symbols are not visible by 
> default unless we export them at the linking stage, either manually or with 
> the help of CreateExportList. However, on Linux, symbols are, by default, 
> with export (namely default) visibility. This brings a gap between the AIX 
> visibility attribute and the GNU visibility attribute. To be backward 
> compatible, on AIX, XL C/C++ would not set all the symbols to be exported 
> like Linux. It might consider symbol without any visibility setting to be an 
> unspecific visibility, which aligns with an old AIX implementation. For such 
> symbols, AIX compiler, linker, and related tools would handle it as before. 
> However, unspecific visibility does not mean that the symbol is internal or 
> invisible at all. It is just a visibility that is specially designed to keep 
> the compatibility.
>
> ...
>
> --
>
> It says in the first sentence: " As we know from the previous article, on 
> AIX, symbols are not visible by default unless we export them at the linking 
> stage, either manually or with the help of CreateExportList". I guess that is 
> why I was under the impression that with xlc12 symbols would not be visible...
>

:) Thanks for that pointer.

I did read:

"Consequently, as we have mentioned at the beginning of this article,
if the programmer does not explicitly specify the visibility attribute
for a symbol, on Linux, the visibility of the symbol could be
thedefault. But on AIX, the visibility would be unspecified."

So I thought, default is "unspecified", which is not hidden.

I just had a look at the libjvm.so from our nightly fastdebug build,
using "nm -g".

I see tons of exports listed, most of which do not have the static
keyword. So, I would expect them to be exported from their compilation
unit, but not from the linked shared library? Am I making a thinking
error here?

Anyway. I do not want to hold up this patch if you guys think it is
okay to ignore the compiler warning, so it is okay by me.

Best Regards, Thomas


> Best regards
> Christoph
>
>> -Original Message-
>> From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
>> Sent: Freitag, 27. April 2018 09:21
>> To: Langer, Christoph 
>> Cc: Volker Simonis ; Baesken, Matthias
>> ; Simonis, Volker ;
>> ppc-aix-port-...@openjdk.java.net; core-libs-...@openjdk.java.net; build-
>> d...@openjdk.java.net
>> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
>> 12.1
>>
>> Hi Christoph
>>
>> On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph
>>  wrote:
>> > Hi Thomas,
>> >
>> > Look at this blog: https://www.ibm.com/developerworks/aix/library/au-
>> aix-symbol-visibility-part2/index.html
>> >
>> > if I understand it correctly, the xlc 12 default behavior should be like 
>> > what
>> we'd expect from -qvisibility=hidden.
>> >
>>
>> Where in this article do you read this?
>>
>> ..Thomas
>>
>> > Best regards
>> > Christoph
>> >
>> >> -Original Message-
>> >> From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf
>> Of
>> >> Thomas Stüfe
>> >> Sent: Freitag, 27. April 2018 06:55
>> >> To: Volker Simonis ; Baesken, Matthias
>> >> 
>> >> Cc: Simonis, Volker ; ppc-aix-port-
>> >> d...@openjdk.java.net; core-libs-...@openjdk.java.net; build-
>> >> d...@openjdk.java.net
>> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on 
>> >> xlc
>> 12.1
>> >>
>> >> 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-
>

Re: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete

[David Holmes]

On 27/04/2018 4:20 AM, Jiangli Zhou wrote:



On Apr 25, 2018, at 10:09 PM, David Holmes  wrote:

On 26/04/2018 2:34 PM, Jiangli Zhou wrote:

Here is the incremental webrev with updates that incorporate all feedbacks:
http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev_inc.02/


Looks good.


Thanks!



One additional comment on test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java - it seems 
insufficient to just check the output for the word "dump". I would expect to see 
something more definitively associated with -Xshare:dump and also a check that it exited 
cleanly (in case we find "core dump”).


I should have of course said "the word Dumping" and "in case we find 
'Dumping core'". :)



With other test cases being removed from appcds/SharedArchiveFile.java, I just 
realized that the test now essentially is the same as the 
jtreg/runtime/SharedArchiveFile/SharedArchiveFile.java test. 
SharedArchiveFile/SharedArchiveFile.java includes more robust checks as you 
suggested and also tests runtime. Your comments above (and fresh morning 
coffee) reminded me that. :-) So I went ahead removed the 
appcds/SharedArchiveFile.java. Please let me know if you want to see the new 
webrev.


No that's fine. Removing the file completely makes sense.

Thanks,
David


Thanks!
Jiangli



Thanks,
David
-


- Filed JDK-8202282 (https://bugs.openjdk.java.net/browse/JDK-8202282) for 
TestCommon.makeCommandLineForAppCDS() cleanup.
- Removed case 2, 3 and 4 in SharedArchiveFile.java.
- Removed UseAppCDS.java test.
- Removed UseAppCDS in various tests.
- Changed to keep the original version of the classlist and renamed to 
classlist.raw.
- Changed check_nonempty_dir_in_shared_path_table() to report all non-empty 
directories in the shared path table entries before exiting VM.
Full webrev:
http://java.se.oracle.com:10065/mdash/jobs/jianzhou-jdk-20180426-0406-20150
Tested all modified tests locally. Rerunning hs-tier1 ~ hs-tier5 tests.
Thanks for all the suggestions!
Jiangli

On Apr 25, 2018, at 5:24 PM, Jiangli Zhou  wrote:

Hi David,


On Apr 25, 2018, at 3:12 PM, David Holmes  wrote:

Hi Jiangli,

On 26/04/2018 3:39 AM, Jiangli Zhou wrote:

Hi David,
Thanks a lot for the review!

On Apr 24, 2018, at 11:17 PM, David Holmes  wrote:

cc'ing build-dev for the makefile change

Hi Jiangli,

On 25/04/2018 10:53 AM, Jiangli Zhou wrote:

Please review the following changes that streamline the support for application 
class data sharing by eliminating the requirement of using -XX:+UseAppCDS to 
enable the feature. The support for application class data sharing is now 
enabled transparently when application classes or platform classes present in 
the classlist or generated archive with -Xshare:dump/on/auto.
RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
Bug: https://bugs.openjdk.java.net/browse/JDK-8182731


These issues are not publicly visible, can you change them to be so?

Done. Thanks for noticing that!



webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/


Overall this seems fine. Thanks for explaining the logic changes below - much 
appreciated!

One query: why was UseAppCDS not removed from the tests (or at least the tests 
you were modifying anyway) ? They will all need updating before 12 when the 
flag is expired.

The usages are left as backwards compatibility check. They also serve the 
testing purpose to make sure the presence of the flag does not cause any 
unexpected behavior. Those are the main reasons why I didn’t remove the flag 
usages in this webrev.


This sounds like you are basically testing whether obsoleting the flag has 
worked correctly.


Right, that was part of the intention.


You don't need to do that through formal testing. A simple run of "java 
-XX:+UseAppCDS" should show the obsoletion warning and that's that. We don't 
maintain an obsolete flag test the way we do for deprecated flags.


That sounds reasonable.



So IMHO there's really no reason to keep the flag in any of the tests. As I 
said they will all have to be removed when the flag is expired in 12.


Ok. I’ll remove the flag from the tests.

Thanks!

Jiangli



Thanks,
David



test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java

Test 2 reference to UseAppCDS seems unnecessary now.
Test 3 is not needed as you're not using any diagnostic flag now.
Test 4 seems unnecessary now.

Will do.


test/hotspot/jtreg/runtime/appcds/TestCommon.java

makeCommandLineForAppCDS should just be removed (yes that will cause some churn 
in the other tests) - but this can be a follow up test cleanup.

Ok.


test/hotspot/jtreg/runtime/appcds/UseAppCDS.java

This test no longer makes much sense to me. The only tests should be that app 
classes get archived and used. It makes no sense to claim to be testing 
-XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you 
don't need to test that -XX:-UseAppCDS has no affect.

Sounds reasonable. I’ll remove UseAppCDS.java. There 

Re: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated

[Michal Vala]

On 04/27/2018 12:55 AM, Kim Barrett wrote:

On Apr 25, 2018, at 10:51 AM, Andrew Hughes  wrote:

On 24 April 2018 at 20:17, Kim Barrett  wrote:

On Apr 23, 2018, at 3:51 AM, Michal Vala  wrote:

Hi,

following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting 
updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887 [2].

webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/

I'm asking for the review and eventually sponsorship.




The patch looks good to me.


The change to os::readdir in os_linux.inline.hpp looks fine.

I was going to suggest that rather than changing perfMemory_linux.cpp to use 
os::readdir in an
unusual and platform-specific way, it should instead just call ::readdir 
directly.  However, neither
of those is right, and that part of the change should not be made; see
https://bugs.openjdk.java.net/browse/JDK-8134540
Much nearly duplicated code for PerfMemory support



I think, in the circumstances, Michal's solution is the best option at
this point.
8134540 looks like a more long-term change currently scheduled for 12 (is
anyone currently working on it?), whereas this fix could go into 11 and remove
a couple of unneeded memory allocations.


Looking a bit deeper, there might be some additional follow-on that could be 
done, eliminating
the second argument to os::readdir.
windows: unused
bsd: freebsd also deprecated readdir_r, I think for similar reasons.
solaris: doc is clear about thread safety issue being about sharing the DIR*
aix: I haven’t looked at it, but would guess it’s similar.

In other words, don’t operate on the DIR* from multiple threads simultaneously, 
and just use
::readdir on non-Windows.  That would all be for another RFE though.




This also seems like a more in-depth separate change and not one that
can be performed
by any of us alone, as we don't test all these platforms. As it
stands, Michal's change affects
Linux and Linux alone, and the addition of the use of NULL will make
it clearer that moving
to an os:readdir is feasible on that platform.


I disagree, and still think the perfMemory_linux.cpp change should be
removed.

(1) The change to perfMemory_linux.cpp is entirely unnecessary to
address the problem this bug is about.

(2) It violates the (implied) protocol for os::readdir.  If
Linux-specific code wants to invoke Linux-specific behavior, it should
do so by calling a Linux-specific API, not abuse an intended to be
portable API.

(3) It minorly interferes with some desirable future work.  If there
were some significant benefit to doing so, I wouldn't give this much
weight, but I don't see a significant benefit.

(4) The only benefit is saving some rare short-term memory
allocations.  I don't think that's worth the above costs.

Note that the Windows version of os::readdir also ignores the second
argument, but all callers provide it anyway.

I've opened a new CR for general os::readdir cleanup.
https://bugs.openjdk.java.net/browse/JDK-8202353



Ok, if we agree on os_linux.inline.hpp part, I think it should go in. Rest can 
be solved in JDK-8202353, which should imho include also removal of second 
argument of os::readdir, once it's unused.


For now, proposed patch looks like this:

--- old/src/hotspot/os/linux/os_linux.inline.hpp2018-04-20 
09:16:34.498343185 +0200
+++ new/src/hotspot/os/linux/os_linux.inline.hpp2018-04-20 
09:16:34.214342670 +0200
@@ -98,26 +98,8 @@

 inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
 {
-// readdir_r has been deprecated since glibc 2.24.
-// See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more details.
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
-
-  dirent* p;
-  int status;
   assert(dirp != NULL, "just checking");
-
-  // NOTE: Linux readdir_r (on RH 6.2 and 7.2 at least) is NOT like the POSIX
-  // version. Here is the doc for this function:
-  // http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_262.html
-
-  if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
-errno = status;
-return NULL;
-  } else
-return p;
-
-#pragma GCC diagnostic pop
+  return ::readdir(dirp);
 }

 inline int os::closedir(DIR *dirp) {



--
Michal Vala
OpenJDK QE
Red Hat Czech

Re: RFR: JDK-8202319: Fix compilation warnings in Solaris debug builds for DevStudio 12.6

[David Holmes]

On 27/04/2018 4:48 PM, Kim Barrett wrote:

On Apr 27, 2018, at 2:11 AM, David Holmes  wrote:

On 27/04/2018 3:32 PM, Kim Barrett wrote:

On Apr 26, 2018, at 6:49 PM, gary.ad...@oracle.com wrote:

Adding build-dev and hotspot-runtime-dev aliases.

 Forwarded Message 
Subject:RFR: JDK-8202319: Fix compilation warnings in Solaris debug 
builds for DevStudio 12.6
Date:   Thu, 26 Apr 2018 12:35:28 -0400
From:   Gary Adams 
Reply-To:   gary.ad...@oracle.com
To: OpenJDK Serviceability 



Getting the sources ready for the next Solaris developer studio toolchain.
Some additional warnings were found in the debug build.

   Issue:https://bugs.openjdk.java.net/browse/JDK-8202319
   Webrev:http://cr.openjdk.java.net/~gadams/8202319/webrev.00/

This update conditionally disables some new error checks, if the
new toolchain is used.

I looked at these, and the warnings are correct, so just disabling them is a 
bit troubling.
The thing is, the code in both cases is attempting to intentionally provoke a 
crash.
But because the code is invoking undefined behavior, executing it might 
actually do
anything, or nothing at all.  So while suppressing the warning might permit 
compilation,
it’s not at all obvious that the compilation will produce anything like the 
desired code.
And that’s also true for platforms that aren’t warning…


True. Perhaps we should just raise a SEGV directly?

David


I like that idea.


Hopefully this should work:

os::signal_raise(os::get_signal_number("SEGV"));

Cheers,
David

Re: Extensionality Improvement in Main.gmk & Docs.gmk to generate docs

[Archana Nogriya]

Thanks Erik,

It will be great if you can sponsor for this contribution please. 


Thanks and Regards
Archana Nogriya 
IBM Java Runtime, Open Java Developer
IBM Hursley
Tel: Internal - 247073, External - +44 (0) 1962 81 7073
Office Mobile: 07500095480
Email: archana.nogr...@uk.ibm.com



From:   Erik Joelsson 
To: Archana Nogriya , 
build-dev@openjdk.java.net
Cc: David Holmes 
Date:   26/04/2018 17:15
Subject:Re: Extensionality Improvement in Main.gmk & Docs.gmk to 
generate docs



Looks reasonable.
/Erik

On 2018-04-26 04:00, Archana Nogriya wrote:
If we have a conditional variable to set "
hotspot-$(JVM_VARIANT_MAIN)-gensrc" target then this can give way to 
alternate VMs like eclipse openj9 to extend that to set it appropriately. 

diff --git a/make/Main.gmk b/make/Main.gmk 
index 731e9c9934..444a835cb4 100644 
--- a/make/Main.gmk 
+++ b/make/Main.gmk 
@@ -830,7 +830,8 @@ else 
   docs-reference-api-modulegraph: exploded-image buildtools-modules 
  
   # The gensrc steps for hotspot and jdk.jdi create html spec files. 
-  docs-jdk-specs: jdk.jdi-gensrc \ 
+  JVM_DOCS_SPEC_TARGET ?= hotspot-$(JVM_VARIANT_MAIN)-gensrc 
+  docs-jdk-specs: $(JVM_DOCS_SPEC_TARGET) jdk.jdi-gensrc \ 
   docs-jdk-index 


##
 


diff --git a/make/Docs.gmk b/make/Docs.gmk 
index 644ffbf74a..73ffb8ebd2 100644 
--- a/make/Docs.gmk 
+++ b/make/Docs.gmk 
@@ -561,12 +561,12 @@ $(eval $(call SetupCopyFiles, COPY_JDWP_PROTOCOL, \ 
 JDK_SPECS_TARGETS += $(COPY_JDWP_PROTOCOL) 
  
#  Get jvmti.html from the main jvm variant (all variants' jvmti.html are 
identical). 
-JVMTI_HTML := 
$(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
-$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \ 
-FILES := $(JVMTI_HTML), \ 
-DEST := $(DOCS_OUTPUTDIR)/specs, \ 
-)) 
-JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) 
+JVMTI_HTML ?= 
$(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
+$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \ 
+FILES := $(JVMTI_HTML), \ 
+DEST := $(DOCS_OUTPUTDIR)/specs, \ 
+)) 
+JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) 
  
Note: This proposal has been tested in local.

Thanks and Regards
Archana Nogriya 
IBM Java Runtime, Open Java Developer
IBM Hursley
Tel: Internal - 247073, External - +44 (0) 1962 81 7073
Office Mobile: 07500095480
Email: archana.nogr...@uk.ibm.com 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Contribution to make/Docs.gmk

[Archana Nogriya]

I am looking for reviewer and sponsor for this contribution, Is anyone who 
can review this please and happy to sponsor for this contribution as 
appropriate. 

Hi, 

"make/Docs.gmk", JDK_MODULES is only sorted with DOCS_MODULES, where It 
should also filter-out MODULES_FILTER for javadocs modules.

# All modules to have docs generated by docs-jdk-api target
>> -JDK_MODULES := $(sort $(DOCS_MODULES))
>> +JDK_MODULES := $(sort $(filter-out $(MODULES_FILTER), 
$(DOCS_MODULES)))
 

Thanks and Regards
Archana Nogriya 
IBM Java Runtime, Open Java Developer
IBM Hursley
Tel: Internal - 247073, External - +44 (0) 1962 81 7073
Office Mobile: 07500095480
Email: archana.nogr...@uk.ibm.com


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: RFR(XL): 8199712: Flight Recorder

[Erik Gahlin]

Hi Magnus,

Sorry about not including build-dev.  See comments inline.



On 2018-04-25 13:06, Erik Gahlin wrote:

Greetings,

Could I have a review of 8199712: Flight Recorder

As mentioned in the preview [1] the tracing backend has been removed. 
Event metadata has been consolidated into a single XML file and event 
classes are now generated by GenerateJfrFiles.java.


Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64.

For details about the feature, see the JEP:
https://bugs.openjdk.java.net/browse/JDK-8193393

Webrev:
http://cr.openjdk.java.net/~egahlin/8199712.0/

Hi Erik,

When posting build changes (files in "make/*"), please always include 
build-dev. Thanks! :-)


This review is for build changes only.

* make/RunTestsPrebuiltSpec.gmk: This file has only a copyright year 
change. It can be reverted.



Will fix.


* make/copy/Copy-jdk.jfr.gmk:
COPY_HOTSPOT_TRACE_FILES should be renamed to something like 
COPY_JFR_METADATA.



Will fix.


The second part is better off rewritten using SetupCopyFiles.

Something like this, written on-the-fly, so might not work. (Email me 
privately if it does not work and you need help.)


JFR_CONF_DIR := $(TOPDIR)/src/jdk.jfr/share/conf/jfr

$(eval $(call SetupCopyFiles, COPY_JFR_CONF, \
  DEST := $(LIB_DST_DIR)/jfr, \
  FILES := $(wildcard $(JFR_CONF_DIR)/*.jfc), \
  FLATTEN := true, \
))

TARGETS += $(COPY_JFR_CONF)


Will look into it.


* make/autoconf/hotspot.m4:
It's a bit unfortunate with the --enable-jfr option. Ideally, this 
should be handled only as a JVM feature (--with-jvm-features=jfr). Try 
this piece of code instead: (Not tested, but should work.)


diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
--- a/make/autoconf/hotspot.m4
+++ b/make/autoconf/hotspot.m4
@@ -26,7 +26,7 @@
 # All valid JVM features, regardless of platform
 VALID_JVM_FEATURES="compiler1 compiler2 zero minimal dtrace jvmti 
jvmci \

 graal vm-structs jni-check services management all-gcs nmt cds \
-static-build link-time-opt aot"
+static-build link-time-opt aot jfr"

 # All valid JVM variants
 VALID_JVM_VARIANTS="server client minimal core zero custom"
@@ -313,6 +313,11 @@
 AC_MSG_ERROR([Specified JVM feature 'vm-structs' requires feature 
'all-gcs'])

   fi

+  # Enable JFR by default, except on linux-sparcv9 and on minimal.
+  if test "x$OPENJDK_TARGET_OS" != xlinux || test 
"x$OPENJDK_TARGET_CPU" != xsparcv9; then

+NON_MINIMAL_FEATURES="$NON_MINIMAL_FEATURES jfr"
+  fi
+
   # Turn on additional features based on other parts of configure
   if test "x$INCLUDE_DTRACE" = "xtrue"; then
 JVM_FEATURES="$JVM_FEATURES dtrace"


Will try it.

Thanks
Erik


Otherwise, build changes look good!

/Magnus




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

[1] 
http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html


Thanks
Erik and Markus

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

[Baesken, Matthias]

> I see tons of exports listed, most of which do not have the static
> keyword. So, I would expect them to be exported from their compilation
> unit, but not from the linked shared library? Am I making a thinking
> error here?

Hi Thomas , I see  "a ton"  of exported symbols as well  when looking into it 
(e.g. libjvm.so)  with dump .
More than one would like to have .

However  for now I think we  should progress with the suggested patch as it is.

Once we switch to xlc 13  (or some follow up release of xlc)  that  supports  
the visibility attributes 
( as decribed in   
https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility/index.html
  )
 we can open a follow up item  with compiler flag adjustment and  adjust 
src/java.base/unix/native/include/jni_md.h , I think this file misses  a 
proper  JNIEXPORT definition for AIX / xlc 13.1  ).
 

Best regards, Matthias



> -Original Message-
> From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
> Sent: Freitag, 27. April 2018 10:04
> To: Langer, Christoph 
> Cc: Volker Simonis ; Baesken, Matthias
> ; Simonis, Volker ;
> ppc-aix-port-...@openjdk.java.net; core-libs-...@openjdk.java.net; build-
> d...@openjdk.java.net
> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
> 12.1
> 
> On Fri, Apr 27, 2018 at 9:27 AM, Langer, Christoph
>  wrote:
> > Hi Thomas,
> >
> > let me cite one section from the article:
> >
> > --
> >
> > Visibility attribute and backward compatibility on AIX
> >
> > As we know from the previous article, on AIX, symbols are not visible by
> default unless we export them at the linking stage, either manually or with
> the help of CreateExportList. However, on Linux, symbols are, by default,
> with export (namely default) visibility. This brings a gap between the AIX
> visibility attribute and the GNU visibility attribute. To be backward
> compatible, on AIX, XL C/C++ would not set all the symbols to be exported
> like Linux. It might consider symbol without any visibility setting to be an
> unspecific visibility, which aligns with an old AIX implementation. For such
> symbols, AIX compiler, linker, and related tools would handle it as before.
> However, unspecific visibility does not mean that the symbol is internal or
> invisible at all. It is just a visibility that is specially designed to keep 
> the
> compatibility.
> >
> > ...
> >
> > --
> >
> > It says in the first sentence: " As we know from the previous article, on 
> > AIX,
> symbols are not visible by default unless we export them at the linking stage,
> either manually or with the help of CreateExportList". I guess that is why I
> was under the impression that with xlc12 symbols would not be visible...
> >
> 
> :) Thanks for that pointer.
> 
> I did read:
> 
> "Consequently, as we have mentioned at the beginning of this article,
> if the programmer does not explicitly specify the visibility attribute
> for a symbol, on Linux, the visibility of the symbol could be
> thedefault. But on AIX, the visibility would be unspecified."
> 
> So I thought, default is "unspecified", which is not hidden.
> 
> I just had a look at the libjvm.so from our nightly fastdebug build,
> using "nm -g".
> 
> I see tons of exports listed, most of which do not have the static
> keyword. So, I would expect them to be exported from their compilation
> unit, but not from the linked shared library? Am I making a thinking
> error here?
> 
> Anyway. I do not want to hold up this patch if you guys think it is
> okay to ignore the compiler warning, so it is okay by me.
> 
> Best Regards, Thomas
> 
> 
> > Best regards
> > Christoph
> >
> >> -Original Message-
> >> From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
> >> Sent: Freitag, 27. April 2018 09:21
> >> To: Langer, Christoph 
> >> Cc: Volker Simonis ; Baesken, Matthias
> >> ; Simonis, Volker
> ;
> >> ppc-aix-port-...@openjdk.java.net; core-libs-...@openjdk.java.net;
> build-
> >> d...@openjdk.java.net
> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc
> 12.1
> >>
> >> Hi Christoph
> >>
> >> On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph
> >>  wrote:
> >> > Hi Thomas,
> >> >
> >> > Look at this blog:
> https://www.ibm.com/developerworks/aix/library/au-
> >> aix-symbol-visibility-part2/index.html
> >> >
> >> > if I understand it correctly, the xlc 12 default behavior should be like
> what
> >> we'd expect from -qvisibility=hidden.
> >> >
> >>
> >> Where in this article do you read this?
> >>
> >> ..Thomas
> >>
> >> > Best regards
> >> > Christoph
> >> >
> >> >> -Original Message-
> >> >> From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On
> Behalf
> >> Of
> >> >> Thomas Stüfe
> >> >> Sent: Freitag, 27. April 2018 06:55
> >> >> To: Volker Simonis ; Baesken, Matthias
> >> >> 
> >> >> Cc: Simonis, Volker ; ppc-aix-port-
> >> >> d...@openjdk.java.net; core-libs-..

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

[Thomas Stüfe]

On Fri, Apr 27, 2018 at 5:01 PM, Baesken, Matthias
 wrote:
>> I see tons of exports listed, most of which do not have the static
>> keyword. So, I would expect them to be exported from their compilation
>> unit, but not from the linked shared library? Am I making a thinking
>> error here?
>
> Hi Thomas , I see  "a ton"  of exported symbols as well  when looking into it 
> (e.g. libjvm.so)  with dump .
> More than one would like to have .
>

Okay, thanks for confirming this! I was not sure if I was using nm
correctly, or if it was lying to me.

> However  for now I think we  should progress with the suggested patch as it 
> is.
>

I agree, patch is fine. Thanks for fixing this.

> Once we switch to xlc 13  (or some follow up release of xlc)  that  supports  
> the visibility attributes
> ( as decribed in   
> https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility/index.html
>   )
>  we can open a follow up item  with compiler flag adjustment and  adjust 
> src/java.base/unix/native/include/jni_md.h , I think this file misses  a 
> proper  JNIEXPORT definition for AIX / xlc 13.1  ).
>

Okay, fine with me.

Best Regards, Thomas

>
> Best regards, Matthias
>
>
>
>> -Original Message-
>> From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
>> Sent: Freitag, 27. April 2018 10:04
>> To: Langer, Christoph 
>> Cc: Volker Simonis ; Baesken, Matthias
>> ; Simonis, Volker ;
>> ppc-aix-port-...@openjdk.java.net; core-libs-...@openjdk.java.net; build-
>> d...@openjdk.java.net
>> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
>> 12.1
>>
>> On Fri, Apr 27, 2018 at 9:27 AM, Langer, Christoph
>>  wrote:
>> > Hi Thomas,
>> >
>> > let me cite one section from the article:
>> >
>> > --
>> >
>> > Visibility attribute and backward compatibility on AIX
>> >
>> > As we know from the previous article, on AIX, symbols are not visible by
>> default unless we export them at the linking stage, either manually or with
>> the help of CreateExportList. However, on Linux, symbols are, by default,
>> with export (namely default) visibility. This brings a gap between the AIX
>> visibility attribute and the GNU visibility attribute. To be backward
>> compatible, on AIX, XL C/C++ would not set all the symbols to be exported
>> like Linux. It might consider symbol without any visibility setting to be an
>> unspecific visibility, which aligns with an old AIX implementation. For such
>> symbols, AIX compiler, linker, and related tools would handle it as before.
>> However, unspecific visibility does not mean that the symbol is internal or
>> invisible at all. It is just a visibility that is specially designed to keep 
>> the
>> compatibility.
>> >
>> > ...
>> >
>> > --
>> >
>> > It says in the first sentence: " As we know from the previous article, on 
>> > AIX,
>> symbols are not visible by default unless we export them at the linking 
>> stage,
>> either manually or with the help of CreateExportList". I guess that is why I
>> was under the impression that with xlc12 symbols would not be visible...
>> >
>>
>> :) Thanks for that pointer.
>>
>> I did read:
>>
>> "Consequently, as we have mentioned at the beginning of this article,
>> if the programmer does not explicitly specify the visibility attribute
>> for a symbol, on Linux, the visibility of the symbol could be
>> thedefault. But on AIX, the visibility would be unspecified."
>>
>> So I thought, default is "unspecified", which is not hidden.
>>
>> I just had a look at the libjvm.so from our nightly fastdebug build,
>> using "nm -g".
>>
>> I see tons of exports listed, most of which do not have the static
>> keyword. So, I would expect them to be exported from their compilation
>> unit, but not from the linked shared library? Am I making a thinking
>> error here?
>>
>> Anyway. I do not want to hold up this patch if you guys think it is
>> okay to ignore the compiler warning, so it is okay by me.
>>
>> Best Regards, Thomas
>>
>>
>> > Best regards
>> > Christoph
>> >
>> >> -Original Message-
>> >> From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
>> >> Sent: Freitag, 27. April 2018 09:21
>> >> To: Langer, Christoph 
>> >> Cc: Volker Simonis ; Baesken, Matthias
>> >> ; Simonis, Volker
>> ;
>> >> ppc-aix-port-...@openjdk.java.net; core-libs-...@openjdk.java.net;
>> build-
>> >> d...@openjdk.java.net
>> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on 
>> >> xlc
>> 12.1
>> >>
>> >> Hi Christoph
>> >>
>> >> On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph
>> >>  wrote:
>> >> > Hi Thomas,
>> >> >
>> >> > Look at this blog:
>> https://www.ibm.com/developerworks/aix/library/au-
>> >> aix-symbol-visibility-part2/index.html
>> >> >
>> >> > if I understand it correctly, the xlc 12 default behavior should be like
>> what
>> >> we'd expect from -qvisibility=hidden.
>> >> >
>> >>
>> >> Where in this article do you read this

Re: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated

[Thomas Stüfe]

This patch looks fine.

I also welcome Kim's proposal of reverting back to readdir(). We
should do this for JDK libraries too, there are still open issues
(e.g. https://bugs.openjdk.java.net/browse/JDK-8166372).

Best Regards, Thomas

On Fri, Apr 27, 2018 at 10:56 AM, Michal Vala  wrote:
>
>
> On 04/27/2018 12:55 AM, Kim Barrett wrote:
>>>
>>> On Apr 25, 2018, at 10:51 AM, Andrew Hughes 
>>> wrote:
>>>
>>> On 24 April 2018 at 20:17, Kim Barrett  wrote:
>
> On Apr 23, 2018, at 3:51 AM, Michal Vala  wrote:
>
> Hi,
>
> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm
> posting updated patch replacing deprecated readdir_r with readdir. Bug ID 
> is
> JDK-8179887 [2].
>
> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
>
> I'm asking for the review and eventually sponsorship.


>>>
>>> The patch looks good to me.
>>>
 The change to os::readdir in os_linux.inline.hpp looks fine.

 I was going to suggest that rather than changing perfMemory_linux.cpp to
 use os::readdir in an
 unusual and platform-specific way, it should instead just call ::readdir
 directly.  However, neither
 of those is right, and that part of the change should not be made; see
 https://bugs.openjdk.java.net/browse/JDK-8134540
 Much nearly duplicated code for PerfMemory support

>>>
>>> I think, in the circumstances, Michal's solution is the best option at
>>> this point.
>>> 8134540 looks like a more long-term change currently scheduled for 12 (is
>>> anyone currently working on it?), whereas this fix could go into 11 and
>>> remove
>>> a couple of unneeded memory allocations.
>>>
 Looking a bit deeper, there might be some additional follow-on that
 could be done, eliminating
 the second argument to os::readdir.
 windows: unused
 bsd: freebsd also deprecated readdir_r, I think for similar reasons.
 solaris: doc is clear about thread safety issue being about sharing the
 DIR*
 aix: I haven’t looked at it, but would guess it’s similar.

 In other words, don’t operate on the DIR* from multiple threads
 simultaneously, and just use
 ::readdir on non-Windows.  That would all be for another RFE though.


>>>
>>> This also seems like a more in-depth separate change and not one that
>>> can be performed
>>> by any of us alone, as we don't test all these platforms. As it
>>> stands, Michal's change affects
>>> Linux and Linux alone, and the addition of the use of NULL will make
>>> it clearer that moving
>>> to an os:readdir is feasible on that platform.
>>
>>
>> I disagree, and still think the perfMemory_linux.cpp change should be
>> removed.
>>
>> (1) The change to perfMemory_linux.cpp is entirely unnecessary to
>> address the problem this bug is about.
>>
>> (2) It violates the (implied) protocol for os::readdir.  If
>> Linux-specific code wants to invoke Linux-specific behavior, it should
>> do so by calling a Linux-specific API, not abuse an intended to be
>> portable API.
>>
>> (3) It minorly interferes with some desirable future work.  If there
>> were some significant benefit to doing so, I wouldn't give this much
>> weight, but I don't see a significant benefit.
>>
>> (4) The only benefit is saving some rare short-term memory
>> allocations.  I don't think that's worth the above costs.
>>
>> Note that the Windows version of os::readdir also ignores the second
>> argument, but all callers provide it anyway.
>>
>> I've opened a new CR for general os::readdir cleanup.
>> https://bugs.openjdk.java.net/browse/JDK-8202353
>>
>
> Ok, if we agree on os_linux.inline.hpp part, I think it should go in. Rest
> can be solved in JDK-8202353, which should imho include also removal of
> second argument of os::readdir, once it's unused.
>
> For now, proposed patch looks like this:
>
> --- old/src/hotspot/os/linux/os_linux.inline.hpp2018-04-20
> 09:16:34.498343185 +0200
> +++ new/src/hotspot/os/linux/os_linux.inline.hpp2018-04-20
> 09:16:34.214342670 +0200
> @@ -98,26 +98,8 @@
>
>  inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
>  {
> -// readdir_r has been deprecated since glibc 2.24.
> -// See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more
> details.
> -#pragma GCC diagnostic push
> -#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> -
> -  dirent* p;
> -  int status;
>assert(dirp != NULL, "just checking");
> -
> -  // NOTE: Linux readdir_r (on RH 6.2 and 7.2 at least) is NOT like the
> POSIX
> -  // version. Here is the doc for this function:
> -  // http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_262.html
> -
> -  if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
> -errno = status;
> -return NULL;
> -  } else
> -return p;
> -
> -#pragma GCC diagnostic pop
> +  return ::readdir(dirp);
>  }
>
>  inline int os::closedir(DIR *dirp) {
>
>
>
>
> --
> Michal Vala
> OpenJDK QE
> Red Hat Czech

Re: Contribution to make/Docs.gmk

[Erik Joelsson]

Looks good, I will take care of this and the other contribution.

/Erik


On 2018-04-27 03:31, Archana Nogriya wrote:

I am looking for reviewer and sponsor for this contribution, Is anyone who
can review this please and happy to sponsor for this contribution as
appropriate.

Hi,

"make/Docs.gmk", JDK_MODULES is only sorted with DOCS_MODULES, where It
should also filter-out MODULES_FILTER for javadocs modules.

# All modules to have docs generated by docs-jdk-api target

-JDK_MODULES := $(sort $(DOCS_MODULES))
+JDK_MODULES := $(sort $(filter-out $(MODULES_FILTER),

$(DOCS_MODULES)))
  


Thanks and Regards
Archana Nogriya
IBM Java Runtime, Open Java Developer
IBM Hursley
Tel: Internal - 247073, External - +44 (0) 1962 81 7073
Office Mobile: 07500095480
Email: archana.nogr...@uk.ibm.com


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated

[Kim Barrett]

> On Apr 27, 2018, at 4:56 AM, Michal Vala  wrote:
> 
> 
> 
> On 04/27/2018 12:55 AM, Kim Barrett wrote:
>>> On Apr 25, 2018, at 10:51 AM, Andrew Hughes  wrote:
>>> 
>>> On 24 April 2018 at 20:17, Kim Barrett  wrote:
> On Apr 23, 2018, at 3:51 AM, Michal Vala  wrote:
> 
> Hi,
> 
> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm 
> posting updated patch replacing deprecated readdir_r with readdir. Bug ID 
> is JDK-8179887 [2].
> 
> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
> 
> I'm asking for the review and eventually sponsorship.
 
>>> 
>>> The patch looks good to me.
>>> 
 The change to os::readdir in os_linux.inline.hpp looks fine.
 
 I was going to suggest that rather than changing perfMemory_linux.cpp to 
 use os::readdir in an
 unusual and platform-specific way, it should instead just call ::readdir 
 directly.  However, neither
 of those is right, and that part of the change should not be made; see
 https://bugs.openjdk.java.net/browse/JDK-8134540
 Much nearly duplicated code for PerfMemory support
 
>>> 
>>> I think, in the circumstances, Michal's solution is the best option at
>>> this point.
>>> 8134540 looks like a more long-term change currently scheduled for 12 (is
>>> anyone currently working on it?), whereas this fix could go into 11 and 
>>> remove
>>> a couple of unneeded memory allocations.
>>> 
 Looking a bit deeper, there might be some additional follow-on that could 
 be done, eliminating
 the second argument to os::readdir.
 windows: unused
 bsd: freebsd also deprecated readdir_r, I think for similar reasons.
 solaris: doc is clear about thread safety issue being about sharing the 
 DIR*
 aix: I haven’t looked at it, but would guess it’s similar.
 
 In other words, don’t operate on the DIR* from multiple threads 
 simultaneously, and just use
 ::readdir on non-Windows.  That would all be for another RFE though.
 
 
>>> 
>>> This also seems like a more in-depth separate change and not one that
>>> can be performed
>>> by any of us alone, as we don't test all these platforms. As it
>>> stands, Michal's change affects
>>> Linux and Linux alone, and the addition of the use of NULL will make
>>> it clearer that moving
>>> to an os:readdir is feasible on that platform.
>> I disagree, and still think the perfMemory_linux.cpp change should be
>> removed.
>> (1) The change to perfMemory_linux.cpp is entirely unnecessary to
>> address the problem this bug is about.
>> (2) It violates the (implied) protocol for os::readdir.  If
>> Linux-specific code wants to invoke Linux-specific behavior, it should
>> do so by calling a Linux-specific API, not abuse an intended to be
>> portable API.
>> (3) It minorly interferes with some desirable future work.  If there
>> were some significant benefit to doing so, I wouldn't give this much
>> weight, but I don't see a significant benefit.
>> (4) The only benefit is saving some rare short-term memory
>> allocations.  I don't think that's worth the above costs.
>> Note that the Windows version of os::readdir also ignores the second
>> argument, but all callers provide it anyway.
>> I've opened a new CR for general os::readdir cleanup.
>> https://bugs.openjdk.java.net/browse/JDK-8202353
> 
> Ok, if we agree on os_linux.inline.hpp part, I think it should go in. Rest 
> can be solved in JDK-8202353, which should imho include also removal of 
> second argument of os::readdir, once it's unused.
> 
> For now, proposed patch looks like this:
> 
> --- old/src/hotspot/os/linux/os_linux.inline.hpp  2018-04-20 
> 09:16:34.498343185 +0200
> +++ new/src/hotspot/os/linux/os_linux.inline.hpp  2018-04-20 
> 09:16:34.214342670 +0200
> @@ -98,26 +98,8 @@
> 
> inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
> {
> -// readdir_r has been deprecated since glibc 2.24.
> -// See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more 
> details.
> -#pragma GCC diagnostic push
> -#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> -
> -  dirent* p;
> -  int status;
>   assert(dirp != NULL, "just checking");
> -
> -  // NOTE: Linux readdir_r (on RH 6.2 and 7.2 at least) is NOT like the POSIX
> -  // version. Here is the doc for this function:
> -  // http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_262.html
> -
> -  if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
> -errno = status;
> -return NULL;
> -  } else
> -return p;
> -
> -#pragma GCC diagnostic pop
> +  return ::readdir(dirp);
> }
> 
> inline int os::closedir(DIR *dirp) {

This looks good.

Re: Extensionality Improvement in Main.gmk & Docs.gmk to generate docs

[Erik Joelsson]

Looking at this again, the first part, in Main.gmk, has already been 
addressed in https://bugs.openjdk.java.net/browse/JDK-8198425. The patch 
for the second part looks weird. The only real change I can see is the 
?= for the jvmti.html file. The rest looks like there is no difference 
(and I cannot think of any change needed there either).


/Erik


On 2018-04-27 02:12, Archana Nogriya wrote:

Thanks Erik,

It will be great if you can sponsor for this contribution please.


Thanks and Regards
Archana Nogriya
IBM Java Runtime, Open Java Developer
IBM Hursley
Tel: Internal - 247073, External - +44 (0) 1962 81 7073
Office Mobile: 07500095480
Email: archana.nogr...@uk.ibm.com



From: Erik Joelsson 
To: Archana Nogriya , 
build-dev@openjdk.java.net

Cc: David Holmes 
Date: 26/04/2018 17:15
Subject: Re: Extensionality Improvement in Main.gmk & Docs.gmk to 
generate docs





Looks reasonable.
/Erik

On 2018-04-26 04:00, Archana Nogriya wrote:
If we have a conditional variable to set 
"hotspot-$(JVM_VARIANT_MAIN)-gensrc" target then this can give way to 
alternate VMs like eclipse openj9 to extend that to set it appropriately.


diff --git a/make/Main.gmk b/make/Main.gmk
index 731e9c9934..444a835cb4 100644
--- a/make/Main.gmk
+++ b/make/Main.gmk
@@ -830,7 +830,8 @@ else
   docs-reference-api-modulegraph: exploded-image buildtools-modules

   # The gensrc steps for hotspot and jdk.jdi create html spec files.
-  docs-jdk-specs: jdk.jdi-gensrc \
+  JVM_DOCS_SPEC_TARGET ?= hotspot-$(JVM_VARIANT_MAIN)-gensrc
+  docs-jdk-specs: $(JVM_DOCS_SPEC_TARGET) jdk.jdi-gensrc \
       docs-jdk-index


##

diff --git a/make/Docs.gmk b/make/Docs.gmk
index 644ffbf74a..73ffb8ebd2 100644
--- a/make/Docs.gmk
+++ b/make/Docs.gmk
@@ -561,12 +561,12 @@ $(eval $(call SetupCopyFiles, COPY_JDWP_PROTOCOL, \
 JDK_SPECS_TARGETS += $(COPY_JDWP_PROTOCOL)

#  Get jvmti.html from the main jvm variant (all variants' jvmti.html 
are identical).
-JVMTI_HTML := 
$(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html

-$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \
-    FILES := $(JVMTI_HTML), \
-    DEST := $(DOCS_OUTPUTDIR)/specs, \
-))
-JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML)
+JVMTI_HTML ?= 
$(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html

+$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \
+    FILES := $(JVMTI_HTML), \
+    DEST := $(DOCS_OUTPUTDIR)/specs, \
+))
+JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML)

Note: This proposal has been tested in local.

Thanks and Regards
Archana Nogriya
IBM Java Runtime, Open Java Developer
IBM Hursley
Tel: Internal - 247073, External - +44 (0) 1962 81 7073
Office Mobile: 07500095480
Email: _archana.nogr...@uk.ibm.com_ 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with 
number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with 
number 741598.

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete

[Jiangli Zhou]

> On Apr 27, 2018, at 1:43 AM, David Holmes  wrote:
> 
> On 27/04/2018 4:20 AM, Jiangli Zhou wrote:
>>> On Apr 25, 2018, at 10:09 PM, David Holmes  wrote:
>>> 
>>> On 26/04/2018 2:34 PM, Jiangli Zhou wrote:
 Here is the incremental webrev with updates that incorporate all feedbacks:
 http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev_inc.02/
>>> 
>>> Looks good.
>> Thanks!
>>> 
>>> One additional comment on 
>>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java - it seems 
>>> insufficient to just check the output for the word "dump". I would expect 
>>> to see something more definitively associated with -Xshare:dump and also a 
>>> check that it exited cleanly (in case we find "core dump”).
> 
> I should have of course said "the word Dumping" and "in case we find 'Dumping 
> core'". :)
> 
>> With other test cases being removed from appcds/SharedArchiveFile.java, I 
>> just realized that the test now essentially is the same as the 
>> jtreg/runtime/SharedArchiveFile/SharedArchiveFile.java test. 
>> SharedArchiveFile/SharedArchiveFile.java includes more robust checks as you 
>> suggested and also tests runtime. Your comments above (and fresh morning 
>> coffee) reminded me that. :-) So I went ahead removed the 
>> appcds/SharedArchiveFile.java. Please let me know if you want to see the new 
>> webrev.
> 
> No that's fine. Removing the file completely makes sense.

Thanks!

Jiangli

> 
> Thanks,
> David
> 
>> Thanks!
>> Jiangli
>>> 
>>> Thanks,
>>> David
>>> -
>>> 
 - Filed JDK-8202282 (https://bugs.openjdk.java.net/browse/JDK-8202282) for 
 TestCommon.makeCommandLineForAppCDS() cleanup.
 - Removed case 2, 3 and 4 in SharedArchiveFile.java.
 - Removed UseAppCDS.java test.
 - Removed UseAppCDS in various tests.
 - Changed to keep the original version of the classlist and renamed to 
 classlist.raw.
 - Changed check_nonempty_dir_in_shared_path_table() to report all 
 non-empty directories in the shared path table entries before exiting VM.
 Full webrev:
 http://java.se.oracle.com:10065/mdash/jobs/jianzhou-jdk-20180426-0406-20150
 Tested all modified tests locally. Rerunning hs-tier1 ~ hs-tier5 tests.
 Thanks for all the suggestions!
 Jiangli
> On Apr 25, 2018, at 5:24 PM, Jiangli Zhou  wrote:
> 
> Hi David,
> 
>> On Apr 25, 2018, at 3:12 PM, David Holmes  
>> wrote:
>> 
>> Hi Jiangli,
>> 
>> On 26/04/2018 3:39 AM, Jiangli Zhou wrote:
>>> Hi David,
>>> Thanks a lot for the review!
 On Apr 24, 2018, at 11:17 PM, David Holmes  
 wrote:
 
 cc'ing build-dev for the makefile change
 
 Hi Jiangli,
 
 On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
> Please review the following changes that streamline the support for 
> application class data sharing by eliminating the requirement of 
> using -XX:+UseAppCDS to enable the feature. The support for 
> application class data sharing is now enabled transparently when 
> application classes or platform classes present in the classlist or 
> generated archive with -Xshare:dump/on/auto.
>   RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>   Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
 
 These issues are not publicly visible, can you change them to be so?
>>> Done. Thanks for noticing that!
 
>   webrev: 
> http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
 
 Overall this seems fine. Thanks for explaining the logic changes below 
 - much appreciated!
 
 One query: why was UseAppCDS not removed from the tests (or at least 
 the tests you were modifying anyway) ? They will all need updating 
 before 12 when the flag is expired.
>>> The usages are left as backwards compatibility check. They also serve 
>>> the testing purpose to make sure the presence of the flag does not 
>>> cause any unexpected behavior. Those are the main reasons why I didn’t 
>>> remove the flag usages in this webrev.
>> 
>> This sounds like you are basically testing whether obsoleting the flag 
>> has worked correctly.
> 
> Right, that was part of the intention.
> 
>> You don't need to do that through formal testing. A simple run of "java 
>> -XX:+UseAppCDS" should show the obsoletion warning and that's that. We 
>> don't maintain an obsolete flag test the way we do for deprecated flags.
> 
> That sounds reasonable.
> 
>> 
>> So IMHO there's really no reason to keep the flag in any of the tests. 
>> As I said they will all have to be removed when the flag is expired in 
>> 12.
> 
> Ok. I’ll remove the flag from the tests.
> 
> Thanks!
> 
> Jiangli
> 
>> 
>> Thanks,
>> David
>> 
 
>>>

Re: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated

[Michal Vala]

On 04/27/2018 06:50 PM, Kim Barrett wrote:

On Apr 27, 2018, at 4:56 AM, Michal Vala  wrote:



On 04/27/2018 12:55 AM, Kim Barrett wrote:

On Apr 25, 2018, at 10:51 AM, Andrew Hughes  wrote:

On 24 April 2018 at 20:17, Kim Barrett  wrote:

On Apr 23, 2018, at 3:51 AM, Michal Vala  wrote:

Hi,

following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting 
updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887 [2].

webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/

I'm asking for the review and eventually sponsorship.




The patch looks good to me.


The change to os::readdir in os_linux.inline.hpp looks fine.

I was going to suggest that rather than changing perfMemory_linux.cpp to use 
os::readdir in an
unusual and platform-specific way, it should instead just call ::readdir 
directly.  However, neither
of those is right, and that part of the change should not be made; see
https://bugs.openjdk.java.net/browse/JDK-8134540
Much nearly duplicated code for PerfMemory support



I think, in the circumstances, Michal's solution is the best option at
this point.
8134540 looks like a more long-term change currently scheduled for 12 (is
anyone currently working on it?), whereas this fix could go into 11 and remove
a couple of unneeded memory allocations.


Looking a bit deeper, there might be some additional follow-on that could be 
done, eliminating
the second argument to os::readdir.
windows: unused
bsd: freebsd also deprecated readdir_r, I think for similar reasons.
solaris: doc is clear about thread safety issue being about sharing the DIR*
aix: I haven’t looked at it, but would guess it’s similar.

In other words, don’t operate on the DIR* from multiple threads simultaneously, 
and just use
::readdir on non-Windows.  That would all be for another RFE though.




This also seems like a more in-depth separate change and not one that
can be performed
by any of us alone, as we don't test all these platforms. As it
stands, Michal's change affects
Linux and Linux alone, and the addition of the use of NULL will make
it clearer that moving
to an os:readdir is feasible on that platform.

I disagree, and still think the perfMemory_linux.cpp change should be
removed.
(1) The change to perfMemory_linux.cpp is entirely unnecessary to
address the problem this bug is about.
(2) It violates the (implied) protocol for os::readdir.  If
Linux-specific code wants to invoke Linux-specific behavior, it should
do so by calling a Linux-specific API, not abuse an intended to be
portable API.
(3) It minorly interferes with some desirable future work.  If there
were some significant benefit to doing so, I wouldn't give this much
weight, but I don't see a significant benefit.
(4) The only benefit is saving some rare short-term memory
allocations.  I don't think that's worth the above costs.
Note that the Windows version of os::readdir also ignores the second
argument, but all callers provide it anyway.
I've opened a new CR for general os::readdir cleanup.
https://bugs.openjdk.java.net/browse/JDK-8202353


Ok, if we agree on os_linux.inline.hpp part, I think it should go in. Rest can 
be solved in JDK-8202353, which should imho include also removal of second 
argument of os::readdir, once it's unused.

For now, proposed patch looks like this:

--- old/src/hotspot/os/linux/os_linux.inline.hpp2018-04-20 
09:16:34.498343185 +0200
+++ new/src/hotspot/os/linux/os_linux.inline.hpp2018-04-20 
09:16:34.214342670 +0200
@@ -98,26 +98,8 @@

inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
{
-// readdir_r has been deprecated since glibc 2.24.
-// See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more details.
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
-
-  dirent* p;
-  int status;
   assert(dirp != NULL, "just checking");
-
-  // NOTE: Linux readdir_r (on RH 6.2 and 7.2 at least) is NOT like the POSIX
-  // version. Here is the doc for this function:
-  // http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_262.html
-
-  if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
-errno = status;
-return NULL;
-  } else
-return p;
-
-#pragma GCC diagnostic pop
+  return ::readdir(dirp);
}

inline int os::closedir(DIR *dirp) {


This looks good.



Thanks!
Someone to sponsor this please?

--
Michal Vala
OpenJDK QE
Red Hat Czech

Re: RFR: JDK-8202319: Fix compilation warnings in Solaris debug builds for DevStudio 12.6

[David Holmes]

We discussed this offline and Gary pointed out that, at least in the 
VMError case the attempt to SEGV by dereferencing zero is one of a 
specific number of crash inducing cases, others of which include trying 
to trigger SEGV at non-zero address and explicit signal raising. So 
changing the code to raise the signal directly is not really appropriate 
- and the code in VMError knows the attempt may not result in a crash.


So I am okay with just disabling the compilation warnings for these two 
cases.


Thanks,
David

On 27/04/2018 6:59 PM, David Holmes wrote:

On 27/04/2018 4:48 PM, Kim Barrett wrote:
On Apr 27, 2018, at 2:11 AM, David Holmes  
wrote:


On 27/04/2018 3:32 PM, Kim Barrett wrote:

On Apr 26, 2018, at 6:49 PM, gary.ad...@oracle.com wrote:

Adding build-dev and hotspot-runtime-dev aliases.

 Forwarded Message 
Subject: RFR: JDK-8202319: Fix compilation warnings in Solaris 
debug builds for DevStudio 12.6

Date: Thu, 26 Apr 2018 12:35:28 -0400
From: Gary Adams 
Reply-To: gary.ad...@oracle.com
To: OpenJDK Serviceability 



Getting the sources ready for the next Solaris developer studio 
toolchain.

Some additional warnings were found in the debug build.

   Issue:https://bugs.openjdk.java.net/browse/JDK-8202319
   Webrev:http://cr.openjdk.java.net/~gadams/8202319/webrev.00/

This update conditionally disables some new error checks, if the
new toolchain is used.
I looked at these, and the warnings are correct, so just disabling 
them is a bit troubling.
The thing is, the code in both cases is attempting to intentionally 
provoke a crash.
But because the code is invoking undefined behavior, executing it 
might actually do
anything, or nothing at all.  So while suppressing the warning might 
permit compilation,
it’s not at all obvious that the compilation will produce anything 
like the desired code.

And that’s also true for platforms that aren’t warning…


True. Perhaps we should just raise a SEGV directly?

David


I like that idea.


Hopefully this should work:

os::signal_raise(os::get_signal_number("SEGV"));

Cheers,
David