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

[David Holmes]

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?


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

Re: RFR: JDK-8198303 - jdk11+1 was build with incorrect GA date as 2018-03-20

[joe darcy]

On 2/21/2018 12:54 PM, Martin Buchholz wrote:


On Tue, Feb 20, 2018 at 11:09 PM, Abhijit Saha  wrote:


It's a retroactive review request. Fix has been integrated after reviewed
internally.

jdk11+1 (first build of jdk11) was promoted with incorrect Release Date.
Need to be updated with correct GA date as per internal release roadmap.


Where are my shiny jdk11+1 binaries for download ?!

It would be nice if version information was always correct, which would
mean part of the checklist of creating a release repo would be setting the
release date of jdk/jdk/ 6 months later and marking it "ea" and updating
the version to self-identify as java N+1.  jdk binaries built from jdk/jdk
have been misidentifying themselves since the jdk 10 repo was created.


Certainly it would be preferable if the version update occurred sooner.

However, binaries build from jdk/jdk have been correctly identifying 
themselves as "JDK 11" since David Holmes pushed the fix for 8173401: 
"Update VERSION_FEATURE for JDK 11" on February 6, 2018.


There are about half a dozen distinct changes that need to occur for a 
full conceptual version update going from JDK N to JDK (N+1). Besides 
the actual version update, there are -source/-target changes to javac, 
minor API changes, etc.


Some of the changes made in JDK 11 b01 were done specifically to ease 
future version updates. This included hardening various tests against 
version updates. Since the version updates are happening more often now, 
there is more motivation to streamline the process (https://xkcd.com/1205/).


-Joe

Re: RFR: JDK-8198303 - jdk11+1 was build with incorrect GA date as 2018-03-20

[Martin Buchholz]

On Tue, Feb 20, 2018 at 11:09 PM, Abhijit Saha  wrote:

> It's a retroactive review request. Fix has been integrated after reviewed
> internally.
>
> jdk11+1 (first build of jdk11) was promoted with incorrect Release Date.
> Need to be updated with correct GA date as per internal release roadmap.
>

Where are my shiny jdk11+1 binaries for download ?!

It would be nice if version information was always correct, which would
mean part of the checklist of creating a release repo would be setting the
release date of jdk/jdk/ 6 months later and marking it "ea" and updating
the version to self-identify as java N+1.  jdk binaries built from jdk/jdk
have been misidentifying themselves since the jdk 10 repo was created.

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

[Erik Joelsson]

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?


/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

Re: RFR: JDK-8198301 - jdk11+1 was built as 'fcs' instead of 'ea'

[Tim Bell]

Abhijit:


It's a retroactive review request. Fix has been integrated after
reviewed internally.

jdk11+1 (first build of jdk11) was promoted with incorrect milestone. It
was built with GA milestone instead of 'ea'. Need to be updated with
correct 'ea' milestone.

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

Webrev: http://cr.openjdk.java.net/~asaha/8198301/webrev.01/


Looks good.

/Tim

RFR: JDK-8198301 - jdk11+1 was built as 'fcs' instead of 'ea'

[Abhijit Saha]

It's a retroactive review request. Fix has been integrated after 
reviewed internally.


jdk11+1 (first build of jdk11) was promoted with incorrect milestone. It 
was built with GA milestone instead of 'ea'. Need to be updated with 
correct 'ea' milestone.


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

Webrev: http://cr.openjdk.java.net/~asaha/8198301/webrev.01/



Thanks
Abhijit

Re: RFR: JDK-8198303 - jdk11+1 was build with incorrect GA date as 2018-03-20

[Magnus Ihse Bursie]

Looks good. 

/Magnus

> 21 feb. 2018 kl. 08:09 skrev Abhijit Saha :
> 
> It's a retroactive review request. Fix has been integrated after reviewed 
> internally.
> 
> jdk11+1 (first build of jdk11) was promoted with incorrect Release Date. Need 
> to be updated with correct GA date as per internal release roadmap.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198303
> 
> Webrev: http://cr.openjdk.java.net/~asaha/8198303/webrev.01/
> 
> 
> Thanks
> Abhijit

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

[Magnus Ihse Bursie]

> 20 feb. 2018 kl. 22:35 skrev Erik Joelsson :
> 
> 
>> On 2018-02-20 12:51, Magnus Ihse Bursie wrote:
>> 
>>> On 2018-02-20 19:05, 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/
>> It seems dtrace disappeared when you sorted the line in 
>> make/devkit/Tools.gmk. There's a new dwp, should it be there?
>> 
> Yes and yes. I added links for all the missing tools (which was dwp and 
> objdump) and removed dtrace which was accidentally added in JDK-8196998 (new 
> devkit with 7.3). Dtrace is actually handled separately a few lines above.

Then I'm ok with it. 

/Magnus

> 
> /Erik
>> Otherwise it looks good.
>> 
>> /Magnus
>> 
>>> 
>>> /Erik
>>> 
>> 
>