What's the position on -Ystruct-dispatch, especially options no-cache, mono-cache, invoke-dynamic?

[Simon Ochsenreither]

Hi everyone!

There doesn't seem to exist a single test for these different structural dispatch implementations. no-cache and mono-cache seem to work (only did some superficial testing), but invoke-dynamic fails:

scala -Ystruct-dispatch:invoke-dynamic
Welcome to Scala version 2.11.0-20130424-145255-b291e28c75 (OpenJDK 64-Bit Server VM, Java 1.7.0_21).
Type in expressions to have them evaluated.
Type :help for more information.

scala> type Foo = AnyRef { def foo: Int }
defined type alias Foo

scala> def getFoo(foo: Foo) = foo.foo
error:
     while compiling: <console>
        during phase: icode
     library version: version 2.11.0-20130424-145255-b291e28c75
    compiler version: version 2.11.0-20130424-145255-b291e28c75
  reconstructed args: -Ystruct-dispatch:invoke-dynamic

  last tree to typer: ApplyDynamic(method foo)
              symbol: method foo (flags: <method> <deferred> <triedcooking>)
   symbol definition: def foo(): Int
                 tpe: Int
       symbol owners: method foo -> $line4 -> package $line4
      context owners: object iw -> package $line5

== Enclosing template or block ==

Template( // val <local $iw>: <notype>, tree.tpe=type
  "java.lang.Object" // parents
  ValDef(
    private
    "_"
    <tpt>
    <empty>
  )
  DefDef( // def <init>(): type
    <method>
    "<init>"
    []
    List(Nil)
    <tpt> // tree.tpe=type
    Block( // tree.tpe=Unit
      Apply( // def <init>(): Object in class Object, tree.tpe=Object
        iw.super."<init>" // def <init>(): Object in class Object, tree.tpe=()Object
        Nil
      )
      ()
    )
  )
)

== Expanded type of tree ==

TypeRef(TypeSymbol(final abstract class Int extends ))

uncaught exception during compilation: RuntimeException("No invokedynamic support yet.") @ scala.sys.package$.error(package.scala:27)
java.lang.RuntimeException: No invokedynamic support yet.
    at scala.sys.package$.error(package.scala:27)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:815)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:122)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:70)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:147)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:97)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:70)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:88)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:66)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.apply(GenICode.scala:62)
    at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:413)
    at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:380)
    at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:380)
    at scala.collection.Iterator$class.foreach(Iterator.scala:743)
    at scala.collection.AbstractIterator.foreach(Iterator.scala:1174)
    at scala.tools.nsc.Global$GlobalPhase.run(Global.scala:380)
    at scala.tools.nsc.backend.icode.GenICode$ICodePhase.run(GenICode.scala:55)
    at scala.tools.nsc.Global$Run.compileUnitsInternal(Global.scala:1518)
    at scala.tools.nsc.Global$Run.compileUnits(Global.scala:1493)
    at scala.tools.nsc.Global$Run.compileSources(Global.scala:1489)
    at scala.tools.nsc.interpreter.IMain.compileSourcesKeepingRun(IMain.scala:408)
    at scala.tools.nsc.interpreter.IMain$ReadEvalPrint.compileAndSaveRun(IMain.scala:820)
    at scala.tools.nsc.interpreter.IMain$ReadEvalPrint.compile(IMain.scala:779)
    at scala.tools.nsc.interpreter.IMain$Request.compile$lzycompute(IMain.scala:924)
    at scala.tools.nsc.interpreter.IMain$Request.compile(IMain.scala:919)
    at scala.tools.nsc.interpreter.IMain.compile(IMain.scala:550)
    at scala.tools.nsc.interpreter.IMain.interpret(IMain.scala:538)
    at scala.tools.nsc.interpreter.IMain.interpret(IMain.scala:536)
    at scala.tools.nsc.interpreter.ILoop.reallyInterpret$1(ILoop.scala:566)
    at scala.tools.nsc.interpreter.ILoop.interpretStartingWith(ILoop.scala:611)
    at scala.tools.nsc.interpreter.ILoop.command(ILoop.scala:523)
    at scala.tools.nsc.interpreter.ILoop.processLine(ILoop.scala:379)
    at scala.tools.nsc.interpreter.ILoop.loop(ILoop.scala:396)
    at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply$mcZ$sp(ILoop.scala:679)
    at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply(ILoop.scala:665)
    at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply(ILoop.scala:665)
    at scala.tools.nsc.util.ScalaClassLoader$.savingContextLoader(ScalaClassLoader.scala:95)
    at scala.tools.nsc.interpreter.ILoop.process(ILoop.scala:665)
    at scala.tools.nsc.MainGenericRunner.runTarget$1(MainGenericRunner.scala:80)
    at scala.tools.nsc.MainGenericRunner.process(MainGenericRunner.scala:93)
    at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:102)
    at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)

That entry seems to have slain the compiler.  Shall I replay
your session? I can re-run each line except the last one.
[y/n]

Should we reduce the amount of options? I have never seen an issue were someone told the mailing list “I have issue X” and the answer was “Use a different setting for -Ystruct-dispatch”.

Bye,

Simon

[Jason Zaugg]

On Fri, May 17, 2013 at 5:02 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

Hi everyone!

There doesn't seem to exist a single test for these different structural dispatch implementations. no-cache and mono-cache seem to work (only did some superficial testing), but invoke-dynamic fails:

Paul and I both suggested we should strip away the options altogether in the discussion of #1902 [1]. Please open a ticket.

-jason

[1] https://github.com/scala/scala/pull/1902

[Grzegorz Kossakowski]

On 17 May 2013 17:16, Jason Zaugg <jza...@gmail.com> wrote:

On Fri, May 17, 2013 at 5:02 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

Hi everyone!

There doesn't seem to exist a single test for these different structural dispatch implementations. no-cache and mono-cache seem to work (only did some superficial testing), but invoke-dynamic fails:

Paul and I both suggested we should strip away the options altogether in the discussion of #1902 [1]. Please open a ticket.

Seconded.

Also, eventually we should implement structural dispatch through invokedynamic (for real). Reflection-based and invokedynamic-based are probably the only two strategies we need to support.

--
Grzegorz Kossakowski

Scalac hacker at Typesafe

twitter: @gkossakowski

github: @gkossakowski

[Simon Ochsenreither]

Agree.

Given that -Y are explicitly defined to be private options, it should be acceptable to get rid of them for 2.11, right?
Or should I mark it as deprecated for 2.11 and remove it in 2.12?

[Adriaan Moors]

Yep, we should feel free to disappear private options.

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

See you at Scala Days (June 10–12, NYC)!

[Simon Ochsenreither]

https://issues.scala-lang.org/browse/SI-7492

Agree. As mentioned in the ticket, I think it makes sense to let the backends decide which approach they want to take instead of allowing people to mix-and-match backends with structural dispatch options (this is exactly the kind of stuff which never gets used or tested).

[Simon Ochsenreither]

Yep, we should feel free to disappear private options.

Yay, already on it! :-)

[Simon Ochsenreither]

https://github.com/scala/scala/pull/2555