Scala Programming Language
  1. Scala Programming Language
  2. SI-5005

@specialize vs. @inline: @specialize wins (unnecessarily)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Scala 2.10.0
    • Component/s: None
    • Labels:

      Description

      The following demonstrates a method which is inlined until its class is specialized, after which it isn't, because the specialized version of the (declared final) method is not final. As a debugging aid, the specialized one is inlined if the call site is in a constructor, just not if it's in the body of a regular method.

      class C[U]() {
        @inline final def apply(x: U): U = x
      }
      
      class C2[@specialized(Boolean) U]() {
        @inline final def apply(x: U): U = x
      }
      
      class B {
        private val cNormal = new C[Boolean]()
        private val cSpec   = new C2[Boolean]()
        
        final def m1 = cNormal(true)
        final def m2 = cSpec(true)
        // ./a.scala:14: warning: Could not inline required method apply$mcZ$sp because it can be overridden.
        //   final def m2 = cSpec(true)
        //                       ^
        // one warning found
      
        // however, here it inlines
        cNormal(true)
        cSpec(true)
      }
      

        Issue Links

          Activity

          Hide
          Aleksandar Prokopec added a comment -

          Here's the branch for that change (I've put annotation checking in the `UnPickler` too):
          https://github.com/axel22/scala-github/tree/feature/spec-pickling

          Show
          Aleksandar Prokopec added a comment - Here's the branch for that change (I've put annotation checking in the `UnPickler` too): https://github.com/axel22/scala-github/tree/feature/spec-pickling
          Hide
          Grzegorz Kossakowski added a comment -

          Check SI-6035 for details on why specialization gets confused and that leads to breaking inlining (due to missing specialized bridge).

          Show
          Grzegorz Kossakowski added a comment - Check SI-6035 for details on why specialization gets confused and that leads to breaking inlining (due to missing specialized bridge).
          Hide
          Grzegorz Kossakowski added a comment -

          I verified that if we fix both SI-6035 and SI-6043 then we get proper inlining in example I have given in the comment above (https://issues.scala-lang.org/browse/SI-5005?focusedCommentId=58618&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-58618).

          Conclusions are the following:

          • inlining doesn't need any fixing
          • once we fix two bugs in specialization both specialization and inlining do work together
          Show
          Grzegorz Kossakowski added a comment - I verified that if we fix both SI-6035 and SI-6043 then we get proper inlining in example I have given in the comment above ( https://issues.scala-lang.org/browse/SI-5005?focusedCommentId=58618&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-58618 ). Conclusions are the following: inlining doesn't need any fixing once we fix two bugs in specialization both specialization and inlining do work together
          Hide
          Erik Osheim added a comment -

          So I went back and revisited this bug based on the state of specialization in master.

          My findings are:

          1. Vlad's test case from February 15th seems to be working in master (that is, there's no explicit call to apply)
          2. Most of Paul's examples are not inlining
          3. Greg's issue is linked to a different bug (SI-6043) which I think is a different issue than some of the others here.

          So, I think it's worth closing this bug and opening a new bug (if necessary) for some of the issues specific to Paul's example (i.e. inferred type of accessors related to inlining) since right now the bug's state is a bit confused.

          If we aren't going to close it, I'd like to get consensus on the test case for this bug (i.e. a source file and the desired output) since right now I'm not clear what it would take to consider it "fixed"

          Show
          Erik Osheim added a comment - So I went back and revisited this bug based on the state of specialization in master. My findings are: 1. Vlad's test case from February 15th seems to be working in master (that is, there's no explicit call to apply) 2. Most of Paul's examples are not inlining 3. Greg's issue is linked to a different bug ( SI-6043 ) which I think is a different issue than some of the others here. So, I think it's worth closing this bug and opening a new bug (if necessary) for some of the issues specific to Paul's example (i.e. inferred type of accessors related to inlining) since right now the bug's state is a bit confused. If we aren't going to close it, I'd like to get consensus on the test case for this bug (i.e. a source file and the desired output) since right now I'm not clear what it would take to consider it "fixed"
          Hide
          Jason Zaugg added a comment -

          I'm following Erik's suggestion to close this ticket.

          Show
          Jason Zaugg added a comment - I'm following Erik's suggestion to close this ticket.

            People

            • Assignee:
              Vlad Ureche
              Reporter:
              Paul Phillips
            • Votes:
              5 Vote for this issue
              Watchers:
              22 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development