inliner heuristics

Xin Tong xerox.time.tech at gmail.com
Mon May 21 15:22:12 PDT 2012


I am also looking at inlining of a polymorphic site. Why is there no guard
inserted which encloses the method that is inlined ? The receiver objects
could vary.

   // Try using the type profile.
    if (call_is_virtual && site_count > 0 && receiver_count > 0) {
      // The major receiver's count >= TypeProfileMajorReceiverPercent of
site_count.
      bool have_major_receiver = (100.*profile.receiver_prob(0) >=
(float)TypeProfileMajorReceiverPercent);
      ciMethod* receiver_method = NULL;
      if (have_major_receiver || profile.morphism() == 1 ||
          (profile.morphism() == 2 && UseBimorphicInlining)) {
        // receiver_method = profile.method();
        // Profiles do not suggest methods now.  Look it up in the major
receiver.
        //  the look up is performed on the profile.receiver(0). The first
receiver is the one mostly seen.
        receiver_method =
call_method->resolve_invoke(jvms->method()->holder(),
                                                      profile.receiver(0));
      }
      if (receiver_method != NULL) {
        // The single majority receiver sufficiently outweighs the minority.

*        // Should there be a guard insert to compare the receiver object
class with the inlined method class ?*

        CallGenerator* hit_cg = this->call_generator(receiver_method,
              vtable_index, !call_is_virtual, jvms, allow_inline,
prof_factor);
        if (hit_cg != NULL) {
          // Look up second receiver.
          CallGenerator* next_hit_cg = NULL;
          ciMethod* next_receiver_method = NULL;

          if (profile.morphism() == 2 && UseBimorphicInlining) {
            // XIN TONG, the second virtual call inlined.
            next_receiver_method =
call_method->resolve_invoke(jvms->method()->holder(),

 profile.receiver(1));
            if (next_receiver_method != NULL) {

*        // Should there be a guard insert to compare the receiver object
class with the inlined method class ?*
*
*
              next_hit_cg = this->call_generator(next_receiver_method,
                                  vtable_index, !call_is_virtual, jvms,
                                  allow_inline, prof_factor);
              if (next_hit_cg != NULL && !next_hit_cg->is_inline() &&
                  have_major_receiver && UseOnlyInlinedBimorphic) {
                  // Skip if we can't inline second receiver's method
                  next_hit_cg = NULL;
              }
            }


On Mon, May 21, 2012 at 3:14 PM, Xin Tong <xerox.time.tech at gmail.com> wrote:

> I am investigating the inliner heuristics in C2 compiler of hotspot. There
> are a few things i do not get.
>
> 1. The inliner heuristics depend on 2 parameters - the call_site_count and
> the invocation_count. The invocation_count is the number of times the
> method is executed in the previous tier. i.e. interpreter for tier 1
> compilation and tier 1 for tier 2 compilation. But what does
> call_site_count represent. the number of callsites of this method within
> the all callers of the method ? It seems it is calculated based on MD0,
> what is the method data ?
>
> 2. Is it true that in theory all methods can be inlined in Java ? how
> about in the hotspot JVM ?
>
> Thanks
>
> Xin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120521/e1b9fe5a/attachment.html 


More information about the hotspot-compiler-dev mailing list