RFR: 8302328: [s390x] Simplify asm_assert definition

[Amit Kumar]

On Fri, 17 Mar 2023 11:02:42 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> So does that make sense to not define them inlined at all ? Because if I do not include `.inline.hpp` then it's doesn't build.
>
>> So does that make sense to not define them inlined at all ? Because if I do not include `.inline.hpp` then it's doesn't build.
> 
> I was going to ask you anyway why you decided to convert the asm_assert stuff to inline methods. In general, you do that for performance reasons. Sometimes, it even helps with code size. Think of simple getter and setter methods, where the call overhead is much larger than the "useful" code.
> 
> The following rules can guide you with "optimization" decisions:
> 
> - Optimize for the release build case (execution time and footprint).
> - Optimize for the hottest code path.
> - Optimize for the "OK" case.
> - The path taken if an error occurred does not need to be as efficient as possible.
> - If an assertion fails, it's the end of the JVM. There is no need to rush. 
> 
> With the inclusion of macroAssembler.inline.hpp in interp_masm.hpp you are out of luck. As Martin stated, this is not acceptable. *.inline.hpp files are only to be included in *.cpp files. There are 63 *.cpp files including interp_masm.hpp. Any of these may require the definitions from macroAssembler.inline.hpp. How to find out which ones? Trial and error.

Thank you @RealLucy, 

I rebased locally and build is fine with new commits as well. So I guess we are good to go..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12822#issuecomment-1523218154