RFR: JDK-8198243: Add build time check for global operator new/delete in object files
erik.joelsson at oracle.com
Thu Feb 22 19:41:12 UTC 2018
On 2018-02-21 21:06, David Holmes wrote:
> On 22/02/2018 4:07 AM, Erik Joelsson wrote:
>> 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.
We could grep for the mangled strings for the operators instead, which
is super fast. Problem is just figuring out all the possible combinations.
> To be honest I'm not sure this pulls its own weight regardless.
>>> On 21/02/2018 4:05 AM, Erik Joelsson wrote:
>>>> 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/
More information about the build-dev