Re: (11) RFR (S) JDK-8198640: VS2017 (LNK4281) Link Warning Against Missed ASLR Optimization

[Lois Foltan]

Thanks Erik!
Lois

On 2/23/2018 4:08 PM, Erik Joelsson wrote:

Looks good.

/Erik


On 2018-02-23 12:11, Lois Foltan wrote:
Please review this fix to ignore linker warning (LNK4281).  This is a 
new linker warning generated by VS2017 v15.5 to "to point out any 
64-bit image specified to link with a lower than 4GB base address 
doesn't get best ASLR optimization". The Hotspot jvm.dll is 
specifically linked with -base:0x800.  As recommended by 
https://developercommunity.visualstudio.com/content/problem/160970/upgrading-from-154-to-155-throw-lnk4281-warning.html, 
this linker warning can be suppressed with -ignore.


open webrev at 
http://cr.openjdk.java.net/~lfoltan/bug_jdk8198640/webrev/

bug link https://bugs.openjdk.java.net/browse/JDK-8198640

Testing (hs-tier1-3 & jdk-tier1-3) in progress

Thanks,
Lois

Re: (11) RFR (S) JDK-8198640: VS2017 (LNK4281) Link Warning Against Missed ASLR Optimization

[Erik Joelsson]

Looks good.

/Erik


On 2018-02-23 12:11, Lois Foltan wrote:
Please review this fix to ignore linker warning (LNK4281).  This is a 
new linker warning generated by VS2017 v15.5 to "to point out any 
64-bit image specified to link with a lower than 4GB base address 
doesn't get best ASLR optimization". The Hotspot jvm.dll is 
specifically linked with -base:0x800.  As recommended by 
https://developercommunity.visualstudio.com/content/problem/160970/upgrading-from-154-to-155-throw-lnk4281-warning.html, 
this linker warning can be suppressed with -ignore.


open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198640/webrev/
bug link https://bugs.openjdk.java.net/browse/JDK-8198640

Testing (hs-tier1-3 & jdk-tier1-3) in progress

Thanks,
Lois

Re: (11) RFR (S) JDK-8198640: VS2017 (LNK4281) Link Warning Against Missed ASLR Optimization

[Lois Foltan]

Thank you for the review Christian!  I have gone forward and created the 
RFE at https://bugs.openjdk.java.net/browse/JDK-8198652.

Lois

On 2/23/2018 3:54 PM, Christian Tornqvist wrote:

Forgot to say that the webrev looks good!


On Feb 23, 2018, at 3:53 PM, Christian Tornqvist 
 wrote:

Sounds like a good plan :)

Thanks,
Christian


On Feb 23, 2018, at 3:22 PM, Lois Foltan  wrote:

On 2/23/2018 3:18 PM, Christian Tornqvist wrote:

Hi Lois,

Why do we link jvm.dll with -base?

Hi Christian,
It is not clear to me why we do, so I was going to follow up with an RFE to 
investigate & suggest the removal of -base if unnecessary.
Lois


Thanks,
Christian


On Feb 23, 2018, at 3:11 PM, Lois Foltan  wrote:

Please review this fix to ignore linker warning (LNK4281).  This is a new linker warning 
generated by VS2017 v15.5 to "to point out any 64-bit image specified to link with a 
lower than 4GB base address doesn't get best ASLR optimization". The Hotspot jvm.dll 
is specifically linked with -base:0x800.  As recommended by 
https://developercommunity.visualstudio.com/content/problem/160970/upgrading-from-154-to-155-throw-lnk4281-warning.html,
 this linker warning can be suppressed with -ignore.

open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198640/webrev/
bug link https://bugs.openjdk.java.net/browse/JDK-8198640

Testing (hs-tier1-3 & jdk-tier1-3) in progress

Thanks,
Lois

Re: (11) RFR (S) JDK-8198640: VS2017 (LNK4281) Link Warning Against Missed ASLR Optimization

[Christian Tornqvist]

Forgot to say that the webrev looks good!

> On Feb 23, 2018, at 3:53 PM, Christian Tornqvist 
>  wrote:
> 
> Sounds like a good plan :)
> 
> Thanks,
> Christian
> 
>>> On Feb 23, 2018, at 3:22 PM, Lois Foltan  wrote:
>>> 
>>> On 2/23/2018 3:18 PM, Christian Tornqvist wrote:
>>> 
>>> Hi Lois,
>>> 
>>> Why do we link jvm.dll with -base?
>> Hi Christian,
>> It is not clear to me why we do, so I was going to follow up with an RFE to 
>> investigate & suggest the removal of -base if unnecessary.
>> Lois
>> 
>>> 
>>> Thanks,
>>> Christian
>>> 
 On Feb 23, 2018, at 3:11 PM, Lois Foltan  wrote:
 
 Please review this fix to ignore linker warning (LNK4281).  This is a new 
 linker warning generated by VS2017 v15.5 to "to point out any 64-bit image 
 specified to link with a lower than 4GB base address doesn't get best ASLR 
 optimization". The Hotspot jvm.dll is specifically linked with 
 -base:0x800.  As recommended by 
 https://developercommunity.visualstudio.com/content/problem/160970/upgrading-from-154-to-155-throw-lnk4281-warning.html,
  this linker warning can be suppressed with -ignore.
 
 open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198640/webrev/
 bug link https://bugs.openjdk.java.net/browse/JDK-8198640
 
 Testing (hs-tier1-3 & jdk-tier1-3) in progress
 
 Thanks,
 Lois
 
 
>> 

Re: (11) RFR (S) JDK-8198640: VS2017 (LNK4281) Link Warning Against Missed ASLR Optimization

[Christian Tornqvist]

Sounds like a good plan :)

Thanks,
Christian

> On Feb 23, 2018, at 3:22 PM, Lois Foltan  wrote:
> 
>> On 2/23/2018 3:18 PM, Christian Tornqvist wrote:
>> 
>> Hi Lois,
>> 
>> Why do we link jvm.dll with -base?
> Hi Christian,
> It is not clear to me why we do, so I was going to follow up with an RFE to 
> investigate & suggest the removal of -base if unnecessary.
> Lois
> 
>> 
>> Thanks,
>> Christian
>> 
>>> On Feb 23, 2018, at 3:11 PM, Lois Foltan  wrote:
>>> 
>>> Please review this fix to ignore linker warning (LNK4281).  This is a new 
>>> linker warning generated by VS2017 v15.5 to "to point out any 64-bit image 
>>> specified to link with a lower than 4GB base address doesn't get best ASLR 
>>> optimization". The Hotspot jvm.dll is specifically linked with 
>>> -base:0x800.  As recommended by 
>>> https://developercommunity.visualstudio.com/content/problem/160970/upgrading-from-154-to-155-throw-lnk4281-warning.html,
>>>  this linker warning can be suppressed with -ignore.
>>> 
>>> open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198640/webrev/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8198640
>>> 
>>> Testing (hs-tier1-3 & jdk-tier1-3) in progress
>>> 
>>> Thanks,
>>> Lois
>>> 
>>> 
> 

Re: (11) RFR (S) JDK-8198640: VS2017 (LNK4281) Link Warning Against Missed ASLR Optimization

[Lois Foltan]

On 2/23/2018 3:18 PM, Christian Tornqvist wrote:


Hi Lois,

Why do we link jvm.dll with -base?

Hi Christian,
It is not clear to me why we do, so I was going to follow up with an RFE 
to investigate & suggest the removal of -base if unnecessary.

Lois



Thanks,
Christian


On Feb 23, 2018, at 3:11 PM, Lois Foltan  wrote:

Please review this fix to ignore linker warning (LNK4281).  This is a new linker warning 
generated by VS2017 v15.5 to "to point out any 64-bit image specified to link with a 
lower than 4GB base address doesn't get best ASLR optimization". The Hotspot jvm.dll 
is specifically linked with -base:0x800.  As recommended by 
https://developercommunity.visualstudio.com/content/problem/160970/upgrading-from-154-to-155-throw-lnk4281-warning.html,
 this linker warning can be suppressed with -ignore.

open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198640/webrev/
bug link https://bugs.openjdk.java.net/browse/JDK-8198640

Testing (hs-tier1-3 & jdk-tier1-3) in progress

Thanks,
Lois

Re: (11) RFR (S) JDK-8198640: VS2017 (LNK4281) Link Warning Against Missed ASLR Optimization

[Christian Tornqvist]

Hi Lois,

Why do we link jvm.dll with -base? 

Thanks,
Christian

> On Feb 23, 2018, at 3:11 PM, Lois Foltan  wrote:
> 
> Please review this fix to ignore linker warning (LNK4281).  This is a new 
> linker warning generated by VS2017 v15.5 to "to point out any 64-bit image 
> specified to link with a lower than 4GB base address doesn't get best ASLR 
> optimization". The Hotspot jvm.dll is specifically linked with 
> -base:0x800.  As recommended by 
> https://developercommunity.visualstudio.com/content/problem/160970/upgrading-from-154-to-155-throw-lnk4281-warning.html,
>  this linker warning can be suppressed with -ignore.
> 
> open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198640/webrev/
> bug link https://bugs.openjdk.java.net/browse/JDK-8198640
> 
> Testing (hs-tier1-3 & jdk-tier1-3) in progress
> 
> Thanks,
> Lois
> 
> 

(11) RFR (S) JDK-8198640: VS2017 (LNK4281) Link Warning Against Missed ASLR Optimization

[Lois Foltan]

Please review this fix to ignore linker warning (LNK4281).  This is a 
new linker warning generated by VS2017 v15.5 to "to point out any 64-bit 
image specified to link with a lower than 4GB base address doesn't get 
best ASLR optimization". The Hotspot jvm.dll is specifically linked with 
-base:0x800.  As recommended by 
https://developercommunity.visualstudio.com/content/problem/160970/upgrading-from-154-to-155-throw-lnk4281-warning.html, 
this linker warning can be suppressed with -ignore.


open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198640/webrev/
bug link https://bugs.openjdk.java.net/browse/JDK-8198640

Testing (hs-tier1-3 & jdk-tier1-3) in progress

Thanks,
Lois

Re: (11) RFR (S) JDK-8198312: VS2017: Upgrade HOTSPOT_BUILD_COMPILER in vm_version.cpp

[Erik Joelsson]

Looks good!

/Erik


On 2018-02-23 11:39, Lois Foltan wrote:

On 2/23/2018 2:31 PM, Erik Joelsson wrote:


On 2018-02-23 11:16, Lois Foltan wrote:

On 2/23/2018 1:05 PM, Erik Joelsson wrote:


Hello Lois,

This looks good, but I would suggest to also add 1900 for VS2015, 
for completeness.
Thanks for the review Erik!  I have updated the webrev to add 1900, 
however, I couldn't find a release # for VS2015, since all 
documentation I could find seemed to indicated that only 2015 and 
updates 1-3 were released.  If you have more info on this let me know!


My installation of 2015 was put in "Microsoft Visual Studio 14.0" 
following the pattern of previous versions (12.0, 11.0, 10.0 etc), so 
I think that would be the appropriate number here. Otherwise I think 
this looks good.


Got it, hopefully final webrev at 
http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312.2/webrev/

Thanks again!
Lois



/Erik

http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312.1/webrev/

Thanks,
Lois



/Erik


On 2018-02-23 09:54, Lois Foltan wrote:
Please review this small fix to set HOTSPOT_BUILD_COMPILER 
correctly for VS2017.


open webrev at 
http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312/webrev/

bug link https://bugs.openjdk.java.net/browse/JDK-8198312

Testing: hs-tier(1-3), jdk-tier(1-3) complete

Thanks,
Lois

Re: (11) RFR (S) JDK-8198312: VS2017: Upgrade HOTSPOT_BUILD_COMPILER in vm_version.cpp

[Lois Foltan]

On 2/23/2018 2:31 PM, Erik Joelsson wrote:


On 2018-02-23 11:16, Lois Foltan wrote:

On 2/23/2018 1:05 PM, Erik Joelsson wrote:


Hello Lois,

This looks good, but I would suggest to also add 1900 for VS2015, 
for completeness.
Thanks for the review Erik!  I have updated the webrev to add 1900, 
however, I couldn't find a release # for VS2015, since all 
documentation I could find seemed to indicated that only 2015 and 
updates 1-3 were released.  If you have more info on this let me know!


My installation of 2015 was put in "Microsoft Visual Studio 14.0" 
following the pattern of previous versions (12.0, 11.0, 10.0 etc), so 
I think that would be the appropriate number here. Otherwise I think 
this looks good.


Got it, hopefully final webrev at 
http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312.2/webrev/

Thanks again!
Lois



/Erik

http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312.1/webrev/

Thanks,
Lois



/Erik


On 2018-02-23 09:54, Lois Foltan wrote:
Please review this small fix to set HOTSPOT_BUILD_COMPILER 
correctly for VS2017.


open webrev at 
http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312/webrev/

bug link https://bugs.openjdk.java.net/browse/JDK-8198312

Testing: hs-tier(1-3), jdk-tier(1-3) complete

Thanks,
Lois

Re: (11) RFR (S) JDK-8198312: VS2017: Upgrade HOTSPOT_BUILD_COMPILER in vm_version.cpp

[Lois Foltan]

Thanks again for the review Erik!
Lois

On 2/23/2018 2:44 PM, Erik Joelsson wrote:


Looks good!

/Erik


On 2018-02-23 11:39, Lois Foltan wrote:

On 2/23/2018 2:31 PM, Erik Joelsson wrote:


On 2018-02-23 11:16, Lois Foltan wrote:

On 2/23/2018 1:05 PM, Erik Joelsson wrote:


Hello Lois,

This looks good, but I would suggest to also add 1900 for VS2015, 
for completeness.
Thanks for the review Erik!  I have updated the webrev to add 1900, 
however, I couldn't find a release # for VS2015, since all 
documentation I could find seemed to indicated that only 2015 and 
updates 1-3 were released.  If you have more info on this let me know!


My installation of 2015 was put in "Microsoft Visual Studio 14.0" 
following the pattern of previous versions (12.0, 11.0, 10.0 etc), 
so I think that would be the appropriate number here. Otherwise I 
think this looks good.


Got it, hopefully final webrev at 
http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312.2/webrev/

Thanks again!
Lois



/Erik

http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312.1/webrev/

Thanks,
Lois



/Erik


On 2018-02-23 09:54, Lois Foltan wrote:
Please review this small fix to set HOTSPOT_BUILD_COMPILER 
correctly for VS2017.


open webrev at 
http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312/webrev/

bug link https://bugs.openjdk.java.net/browse/JDK-8198312

Testing: hs-tier(1-3), jdk-tier(1-3) complete

Thanks,
Lois

Re: (11) RFR (S) JDK-8198312: VS2017: Upgrade HOTSPOT_BUILD_COMPILER in vm_version.cpp

[Erik Joelsson]

On 2018-02-23 11:16, Lois Foltan wrote:

On 2/23/2018 1:05 PM, Erik Joelsson wrote:


Hello Lois,

This looks good, but I would suggest to also add 1900 for VS2015, for 
completeness.
Thanks for the review Erik!  I have updated the webrev to add 1900, 
however, I couldn't find a release # for VS2015, since all 
documentation I could find seemed to indicated that only 2015 and 
updates 1-3 were released.  If you have more info on this let me know!


My installation of 2015 was put in "Microsoft Visual Studio 14.0" 
following the pattern of previous versions (12.0, 11.0, 10.0 etc), so I 
think that would be the appropriate number here. Otherwise I think this 
looks good.


/Erik

http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312.1/webrev/

Thanks,
Lois



/Erik


On 2018-02-23 09:54, Lois Foltan wrote:
Please review this small fix to set HOTSPOT_BUILD_COMPILER correctly 
for VS2017.


open webrev at 
http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312/webrev/

bug link https://bugs.openjdk.java.net/browse/JDK-8198312

Testing: hs-tier(1-3), jdk-tier(1-3) complete

Thanks,
Lois

Re: (11) RFR (S) JDK-8198312: VS2017: Upgrade HOTSPOT_BUILD_COMPILER in vm_version.cpp

[Lois Foltan]

On 2/23/2018 1:05 PM, Erik Joelsson wrote:


Hello Lois,

This looks good, but I would suggest to also add 1900 for VS2015, for 
completeness.
Thanks for the review Erik!  I have updated the webrev to add 1900, 
however, I couldn't find a release # for VS2015, since all documentation 
I could find seemed to indicated that only 2015 and updates 1-3 were 
released.  If you have more info on this let me know!


http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312.1/webrev/

Thanks,
Lois



/Erik


On 2018-02-23 09:54, Lois Foltan wrote:
Please review this small fix to set HOTSPOT_BUILD_COMPILER correctly 
for VS2017.


open webrev at 
http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312/webrev/

bug link https://bugs.openjdk.java.net/browse/JDK-8198312

Testing: hs-tier(1-3), jdk-tier(1-3) complete

Thanks,
Lois

Re: (11) RFR (S) JDK-8198312: VS2017: Upgrade HOTSPOT_BUILD_COMPILER in vm_version.cpp

[Erik Joelsson]

Hello Lois,

This looks good, but I would suggest to also add 1900 for VS2015, for 
completeness.


/Erik


On 2018-02-23 09:54, Lois Foltan wrote:
Please review this small fix to set HOTSPOT_BUILD_COMPILER correctly 
for VS2017.


open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312/webrev/
bug link https://bugs.openjdk.java.net/browse/JDK-8198312

Testing: hs-tier(1-3), jdk-tier(1-3) complete

Thanks,
Lois

(11) RFR (S) JDK-8198312: VS2017: Upgrade HOTSPOT_BUILD_COMPILER in vm_version.cpp

[Lois Foltan]

Please review this small fix to set HOTSPOT_BUILD_COMPILER correctly for 
VS2017.


open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8198312/webrev/
bug link https://bugs.openjdk.java.net/browse/JDK-8198312

Testing: hs-tier(1-3), jdk-tier(1-3) complete

Thanks,
Lois

Re: RFR: JDK-8198627 JDK-8198318 broke readlink testing

[Phil Race]

+1 .

This fixed it for me when I tried it yesterday.

-phil.

On 02/23/2018 06:52 AM, Erik Joelsson wrote:
Looks good and thanks for picking this up! I never got around to it 
yesterday.


/Erik


On 2018-02-23 05:24, Magnus Ihse Bursie wrote:

The if line introduced in JDK-8198318 is missing a "test".
Thanks to Jon and Erik for discovering the problem and the solution.

Bug: https://bugs.openjdk.java.net/browse/JDK-8198627
Patch inline:

diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4
--- a/make/autoconf/basics.m4
+++ b/make/autoconf/basics.m4
@@ -263,7 +263,7 @@
   READLINK_TESTED=yes
 fi

-if test "x$READLINK" != x && "x$READLINK_ISGNU" != x; then
+if test "x$READLINK" != x && test "x$READLINK_ISGNU" != x; then
   $1=`$READLINK -f [$]$1`
 else
   # Save the current directory for restoring afterwards

/Magnus

Re: RFR: JDK-8198627 JDK-8198318 broke readlink testing

[Volker Simonis]

Good patch, Magnus!

We've been affected by this as well but instead of digging deeper into
the problem we've installed "readlink" on our AIX build machines,
where it wasn't available until now. Good to know that "readlink" is
still not a mandatory requirement for the build :)


On Fri, Feb 23, 2018 at 2:24 PM, Magnus Ihse Bursie
 wrote:
> The if line introduced in JDK-8198318 is missing a "test".
> Thanks to Jon and Erik for discovering the problem and the solution.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198627
> Patch inline:
>
> diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4
> --- a/make/autoconf/basics.m4
> +++ b/make/autoconf/basics.m4
> @@ -263,7 +263,7 @@
>READLINK_TESTED=yes
>  fi
>
> -if test "x$READLINK" != x && "x$READLINK_ISGNU" != x; then
> +if test "x$READLINK" != x && test "x$READLINK_ISGNU" != x; then
>$1=`$READLINK -f [$]$1`
>  else
># Save the current directory for restoring afterwards
>
> /Magnus

Re: RFR: JDK-8198627 JDK-8198318 broke readlink testing

[Tim Bell]

Magnus-

Looks good to me as well.

Thanks-

/Tim

On 02/23/18 06:52, Erik Joelsson wrote:

Looks good and thanks for picking this up! I never got around to it
yesterday.

/Erik


On 2018-02-23 05:24, Magnus Ihse Bursie wrote:

The if line introduced in JDK-8198318 is missing a "test".
Thanks to Jon and Erik for discovering the problem and the solution.

Bug: https://bugs.openjdk.java.net/browse/JDK-8198627
Patch inline:

diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4
--- a/make/autoconf/basics.m4
+++ b/make/autoconf/basics.m4
@@ -263,7 +263,7 @@
   READLINK_TESTED=yes
 fi

-if test "x$READLINK" != x && "x$READLINK_ISGNU" != x; then
+if test "x$READLINK" != x && test "x$READLINK_ISGNU" != x; then
   $1=`$READLINK -f [$]$1`
 else
   # Save the current directory for restoring afterwards

/Magnus

Re: RFR: JDK-8198627 JDK-8198318 broke readlink testing

[Erik Joelsson]

Looks good and thanks for picking this up! I never got around to it 
yesterday.


/Erik


On 2018-02-23 05:24, Magnus Ihse Bursie wrote:

The if line introduced in JDK-8198318 is missing a "test".
Thanks to Jon and Erik for discovering the problem and the solution.

Bug: https://bugs.openjdk.java.net/browse/JDK-8198627
Patch inline:

diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4
--- a/make/autoconf/basics.m4
+++ b/make/autoconf/basics.m4
@@ -263,7 +263,7 @@
   READLINK_TESTED=yes
 fi

-    if test "x$READLINK" != x && "x$READLINK_ISGNU" != x; then
+    if test "x$READLINK" != x && test "x$READLINK_ISGNU" != x; then
   $1=`$READLINK -f [$]$1`
 else
   # Save the current directory for restoring afterwards

/Magnus

Re: RFR: JDK-8198243: Add build time check for global operator new/delete in object files

[Magnus Ihse Bursie]

On 2018-02-22 20:41, Erik Joelsson wrote:



On 2018-02-21 21:06, David Holmes wrote:

On 22/02/2018 4:07 AM, Erik Joelsson wrote:

Hello,


On 2018-02-20 21:33, David Holmes wrote:


a) how much time it adds to the build?

I have not done extensive testing, but on my Linux workstation with 
32 hw threads, building just hotspot release build from a clean 
workspace increased maybe 1 or 2 seconds (at around 90s total), but 
the variance was around the same amount as that.

b) why this doesn't work for Solaris Studio?

I didn't put a lot of effort into trying to figure it out. The check 
used was provided by Kim Barrett, for Linux only. I figured it would 
be simple enough to get it to work on mac and succeeded there. It 
should certainly be possible to implement a similar check on 
Solaris, but is it worth the time to do it? Both development time 
and increased build time on one of the slower build platforms?


Depends how concerned we are with detecting this problem in OS 
specific source code?


I investigated this some more. I was able to do it successfully, but 
the build time cost is way too large here. The culprit is c++filt on 
Solaris which is incredibly costly, and the gnu version does not 
demangle Solaris Studio symbols. I don't think we should do this on 
Solaris.

I agree, it's not worth it.

Not all programmer's mistakes are reasonable to catch in technical 
traps. It we *should* spend time on getting automatic tool for keeping 
code quality up (and, yes, I really do think we should), there's most 
likely to be much better areas to spend that effort in, in making a lot 
of prone-to-break scripts for catching a single kind of problem.


/Magnus



We could grep for the mangled strings for the operators instead, which 
is super fast. Problem is just figuring out all the possible 
combinations.


/Erik

To be honest I'm not sure this pulls its own weight regardless.

David


/Erik

Thanks,
David

On 21/02/2018 4:05 AM, Erik Joelsson wrote:

Hello,

This patch adds a build time check for uses of global operators 
new and delete in hotspot C++ code. The check is only run with 
toolchains GCC and Clang (Linux and Macos builds). I have also 
modified the Oracle devkit on Linux to add the necessary symlink 
so that objdump will get picked up by configure.


This change is depending on several fixes removing such uses that 
are currently in jdk/hs so this change will need to be pushed 
there as well.


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

Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/

/Erik

RFR: JDK-8198627 JDK-8198318 broke readlink testing

[Magnus Ihse Bursie]

The if line introduced in JDK-8198318 is missing a "test".
Thanks to Jon and Erik for discovering the problem and the solution.

Bug: https://bugs.openjdk.java.net/browse/JDK-8198627
Patch inline:

diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4
--- a/make/autoconf/basics.m4
+++ b/make/autoconf/basics.m4
@@ -263,7 +263,7 @@
   READLINK_TESTED=yes
 fi

-    if test "x$READLINK" != x && "x$READLINK_ISGNU" != x; then
+    if test "x$READLINK" != x && test "x$READLINK_ISGNU" != x; then
   $1=`$READLINK -f [$]$1`
 else
   # Save the current directory for restoring afterwards

/Magnus

Re: RFR: JDK-8198569: SetupTextFileProcessing should use sed with 'g'

[Magnus Ihse Bursie]

On 2018-02-22 23:26, Erik Joelsson wrote:
I'm currently trying to use SetupTextFileProcessing with a file where 
the same replacement string appears twice on the same row. This 
doesn't work. To fix it, I would like to add /g on the sed replacement 
expressions.

Oops :)


Webrev: http://cr.openjdk.java.net/~erikj/8198569/webrev.01/


Looks good.

/Magnus



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

/Erik

Re: RFR(S): 8196992: Resolve disabled warnings for libdt_socket

[Magnus Ihse Bursie]

On 2018-02-23 02:03, Chris Plummer wrote:

Hello,

Please review the following:

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

diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk 
b/make/lib/Lib-jdk.jdwp.agent.gmk

--- a/make/lib/Lib-jdk.jdwp.agent.gmk
+++ b/make/lib/Lib-jdk.jdwp.agent.gmk
@@ -43,7 +43,6 @@
 OPTIMIZATION := LOW, \
 CFLAGS := $(CFLAGS_JDKLIB) -DUSE_MMAP \
 $(LIBDT_SOCKET_CPPFLAGS), \
-    DISABLED_WARNINGS_gcc := shift-negative-value, \
 MAPFILE := $(TOPDIR)/make/mapfiles/libdt_socket/mapfile-vers, \
 LDFLAGS := $(LDFLAGS_JDKLIB) \
 $(call SET_SHARED_LIBRARY_ORIGIN), \

Looks good. Thanks for fixing these code quality issues!

/Magnus


This change is undoing the makefile change done as part of 
JDK-8196985. The only warning that was turning up in libdt_socket code 
before JDK-8196985 was done has already been fixed by JDK-8196909. 
Thus no warnings need to be fixed.


After removing the above makefile code, I tested by building with the 
new toolchain. As a first test I undid the socketTransport.cpp fix 
from JDK-8196909 to verify that the new toolchain exposed the warning. 
Then I reverted socketTransport.cpp back to tip sources and saw no 
warnings with the new toolchain.


thanks,

Chris

Re: RFR(S): 8196992: Resolve disabled warnings for libdt_socket

[serguei.spit...@oracle.com]

Chris,

This looks good to me too.

Thanks,
Serguei


On 2/23/18 00:48, Langer, Christoph wrote:

Looks good, Chris.


-Original Message-
From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf Of
Chris Plummer
Sent: Freitag, 23. Februar 2018 02:04
To: build-dev@openjdk.java.net build-dev ;
serviceability-dev 
Subject: RFR(S): 8196992: Resolve disabled warnings for libdt_socket

Hello,

Please review the following:

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

diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk
b/make/lib/Lib-jdk.jdwp.agent.gmk
--- a/make/lib/Lib-jdk.jdwp.agent.gmk
+++ b/make/lib/Lib-jdk.jdwp.agent.gmk
@@ -43,7 +43,6 @@
   OPTIMIZATION := LOW, \
   CFLAGS := $(CFLAGS_JDKLIB) -DUSE_MMAP \
   $(LIBDT_SOCKET_CPPFLAGS), \
-    DISABLED_WARNINGS_gcc := shift-negative-value, \
   MAPFILE := $(TOPDIR)/make/mapfiles/libdt_socket/mapfile-vers, \
   LDFLAGS := $(LDFLAGS_JDKLIB) \
   $(call SET_SHARED_LIBRARY_ORIGIN), \

This change is undoing the makefile change done as part of JDK-8196985.
The only warning that was turning up in libdt_socket code before
JDK-8196985 was done has already been fixed by JDK-8196909. Thus no
warnings need to be fixed.

After removing the above makefile code, I tested by building with the
new toolchain. As a first test I undid the socketTransport.cpp fix from
JDK-8196909 to verify that the new toolchain exposed the warning. Then I
reverted socketTransport.cpp back to tip sources and saw no warnings
with the new toolchain.

thanks,

Chris

RE: RFR(S): 8196992: Resolve disabled warnings for libdt_socket

[Langer, Christoph]

Looks good, Chris.

> -Original Message-
> From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf Of
> Chris Plummer
> Sent: Freitag, 23. Februar 2018 02:04
> To: build-dev@openjdk.java.net build-dev ;
> serviceability-dev 
> Subject: RFR(S): 8196992: Resolve disabled warnings for libdt_socket
> 
> Hello,
> 
> Please review the following:
> 
> https://bugs.openjdk.java.net/browse/JDK-8196992
> 
> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk
> b/make/lib/Lib-jdk.jdwp.agent.gmk
> --- a/make/lib/Lib-jdk.jdwp.agent.gmk
> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk
> @@ -43,7 +43,6 @@
>   OPTIMIZATION := LOW, \
>   CFLAGS := $(CFLAGS_JDKLIB) -DUSE_MMAP \
>   $(LIBDT_SOCKET_CPPFLAGS), \
> -    DISABLED_WARNINGS_gcc := shift-negative-value, \
>   MAPFILE := $(TOPDIR)/make/mapfiles/libdt_socket/mapfile-vers, \
>   LDFLAGS := $(LDFLAGS_JDKLIB) \
>   $(call SET_SHARED_LIBRARY_ORIGIN), \
> 
> This change is undoing the makefile change done as part of JDK-8196985.
> The only warning that was turning up in libdt_socket code before
> JDK-8196985 was done has already been fixed by JDK-8196909. Thus no
> warnings need to be fixed.
> 
> After removing the above makefile code, I tested by building with the
> new toolchain. As a first test I undid the socketTransport.cpp fix from
> JDK-8196909 to verify that the new toolchain exposed the warning. Then I
> reverted socketTransport.cpp back to tip sources and saw no warnings
> with the new toolchain.
> 
> thanks,
> 
> Chris