RFR (L, tedious) 8199809: Don't include frame.inline.hpp and other.inline.hpp from .hpp files (original) (raw)

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Wed Mar 21 18:24:29 UTC 2018

On 3/21/18 1:36 PM, Stefan Karlsson wrote:

Hi Coleen,

This looks good to me (minus the comments from others in this thread). I wonder about the functions in the new vframe.inline.hpp file: http://cr.openjdk.java.net/~coleenp/8199809.01/webrev/src/hotspot/share/runtime/vframe.inline.hpp.html

I thought vframeStreamCommon::fillfromframe and friends were going to move a .cpp, and then we could get rid of even more .inline.hpp includes. Did you change your mind about that?

Yes.  There is code that cares about stack walking performance, and I didn't want to risk changing this. Coleen

Thanks, StefanK

On 2018-03-21 01:08, coleen.phillimore at oracle.com wrote: Summary: Remove frame.inline.hpp,etc from header files and adjust transitive includes.

Tested with mach5 tier1 on Oracle platforms: linux-x64, solaris-sparc, windows-x64.  Built with open-only sources using --disable-precompiled-headers on linux-x64, built with zero (also disable precompiled headers).  Roman built with aarch64, and have request to build ppc, etc.  (Please test this patch!) Semi-interesting details:  moved SignatureHandlerGenerator constructor to cpp file, moved interpreterframestackdirection() to target specific hpp files (even though they're all -1), pdlastframe to thread.cpp because there isn't a thread.inline.hpp file, lastly moved InterpreterRuntime::LastFrameAccessor into interpreterRuntime.cpp file, and a few other functions moved in shared code. This is the last of this include file technical debt cleanup that I'm going to do.  See bug for more information. open webrev at http://cr.openjdk.java.net/~coleenp/8199809.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8199809 I'll update the copyrights when I commit. Thanks, Coleen

More information about the hotspot-dev mailing list