RFR(M): 8037821: Account for trampoline stubs when estimating code buffer sizes

[Lindenmaier, Goetz]

Hi Lutz,

The changes are good on ppc.  Thanks for fixing this.

Best regards,
  Goetz.

-----Original Message-----
From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz
Sent: Thursday, March 20, 2014 11:52 AM
To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net
Subject: RFR(M): 8037821: Account for trampoline stubs when estimating code buffer sizes

Hi all, 

I would welcome reviews for my change. I would need a sponsor as well. 

The initial reason for the change was fixing size calculations for stubs section and relocations (relevant for PPC port only). On PowerPC, far calls require "trampoline code" in the stubs section. The space needed for these trampoline stubs was not accounted for in shorten_branches processing. The additional relocation entries were "forgotten" as well. Correct a-priori calculation of the section sizes is desirable because it avoids the need for later resizing.

To avoid platform-specific code in shorten_branches, I introduced a small class CallStubImpl in the architecture description (.ad) files. The class declaration makes its way to the ad_<arch>.hpp file which is included in share/vm/opto/output.cpp anyway. Because the size functions are contained in the class declaration, they are inlined at call sites (and optimized away in most cases). 

I took the opportunity to get rid of the extern declarations for
  size_exception_handler()
  size_deopt_handler()
in share/vm/opto/output.cpp altogether. Using the trampoline stubs approach as a template, I introduced another small class HandlerImpl in the architecture description (.ad) files. It declares and defines the size and emitter functions for the exception and depot handlers. Program logic is not changed. 

Webrev:
http://cr.openjdk.java.net/~goetz/webrevs/8037802/webrev.00/

Testing:
Automated tests, including SPEC benchmarks and the JCK suite, did not reveal any issues.

Thanks a lot!
Lutz 

Lutz Schmidt | SAP AG | Walldorf, Germany