This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Regression in specialization

4 replies
gkossakowski
Joined: 2010-03-11,
User offline. Last seen 33 weeks 5 days ago.
Hi,
There's regression in specialization logic caused by following commit: https://github.com/scala/scala/commit/d4a2e5ba3cc957bb162f11935ddd34bbd16e0cfd
This snippet illustrates the problem:
tsf-wpa-1-4252:scala-2.10.0.r25825-b20111013023509 grek$ ./bin/scalaWelcome to Scala version 2.10.0.r25825-b20111013020230 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_27). Type in expressions to have them evaluated.Type :help for more information.
scala> class Foo extends (Double => Double) {     | def apply(x: Double) = x      | }defined class Foo
scala> new Foojava.lang.NoSuchMethodError: scala.Function1$mcDD$sp$class.$init$(Lscala/Function1$mcDD$sp;)V at Foo.<init>(<console>:7) at .<init>(<console>:9) at .<clinit>(<console>) at .<init>(<console>:11) at .<clinit>(<console>) at $print(<console>) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at scala.tools.nsc.interpreter.IMain$ReadEvalPrint.call(IMain.scala:736) at scala.tools.nsc.interpreter.IMain$Request$$anonfun$15.apply(IMain.scala:976) at scala.tools.nsc.interpreter.Line$$anonfun$1.apply$mcV$sp(Line.scala:43) at scala.tools.nsc.io.package$$anon$2.run(package.scala:19) at java.lang.Thread.run(Thread.java:680)
If you compare bytecode before d4a2e5ba and after that commit you'll notice, that $init$ method doesn't take specialized argument corresponding to trait's "this" as specialized one. I'll go ahead and revert the commit so better fix for the original problem can be worked on.
--
Grzegorz Kossakowski

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Regression in specialization

On Thu, Oct 13, 2011 at 3:37 PM, Grzegorz Kossakowski
wrote:
> Hi,
> There's regression in specialization logic caused by following
> commit: https://github.com/scala/scala/commit/d4a2e5ba3cc957bb162f11935ddd34bbd16e0cfd

Interesting, interesting. I spent something like five hours on those
two lines, too. I am grateful you're in there catching these things
quickly.

gkossakowski
Joined: 2010-03-11,
User offline. Last seen 33 weeks 5 days ago.
Re: Regression in specialization
On 14 October 2011 01:25, Paul Phillips <paulp [at] improving [dot] org> wrote:
On Thu, Oct 13, 2011 at 3:37 PM, Grzegorz Kossakowski
<grzegorz [dot] kossakowski [at] gmail [dot] com> wrote:
> Hi,
> There's regression in specialization logic caused by following
> commit: https://github.com/scala/scala/commit/d4a2e5ba3cc957bb162f11935ddd34bbd16e0cfd

Interesting, interesting.  I spent something like five hours on those
two lines, too.  I am grateful you're in there catching these things
quickly.

I looked at your commit while chasing this bug and I was fairly sure it's not the guilty one. Other (more knowledgeable) people agreed. I was surprised when I finally reverted and rechecked generated bytecode.
I still don't know how to connect dots here.

--
Grzegorz Kossakowski

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Regression in specialization

On Thu, Oct 13, 2011 at 4:34 PM, Grzegorz Kossakowski
wrote:
> I still don't know how to connect dots here.

My trust dot-connecting tape carried the day. It came down to this:

scala> trait Foo1 { }
defined trait Foo1

scala> trait Foo2 { self => }
defined trait Foo2

scala> intp("Foo1").thisSym
res0: $r.intp.global.Symbol = trait Foo1

scala> intp("Foo2").thisSym
res1: $r.intp.global.Symbol = value self

And through whatever quirk of history, FunctionN is defined with an
unused self, whereas TupleN is not. Which is why it only impacted
FunctionN and AbstractFunctionN.

Seems pretty sketchy that thisSym might be a TypeSymbol or a
TermSymbol, and that a meaningless change at the language level can
actually flip it from one to the other. I think it would be less
surprising if thisSym were NoSymbol by default (rather than "this" as
it presently is.)

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: Regression in specialization

On Fri, Oct 14, 2011 at 6:40 AM, Paul Phillips wrote:
> On Thu, Oct 13, 2011 at 4:34 PM, Grzegorz Kossakowski
> wrote:
>> I still don't know how to connect dots here.
>
> My trust dot-connecting tape carried the day.  It came down to this:
>
>  scala> trait Foo1 { }
>  defined trait Foo1
>
>  scala> trait Foo2 { self => }
>  defined trait Foo2
>
>  scala> intp("Foo1").thisSym
>  res0: $r.intp.global.Symbol = trait Foo1
>
>  scala> intp("Foo2").thisSym
>  res1: $r.intp.global.Symbol = value self
>
> And through whatever quirk of history, FunctionN is defined with an
> unused self, whereas TupleN is not.  Which is why it only impacted
> FunctionN and AbstractFunctionN.
>
> Seems pretty sketchy that thisSym might be a TypeSymbol or a
> TermSymbol, and that a meaningless change at the language level can
> actually flip it from one to the other.  I think it would be less
> surprising if thisSym were NoSymbol by default (rather than "this" as
> it presently is.)
>
The reason `thisSym' is `this' is so that thisType can be this.thisSym.tpe.
It's a trick to shave some cycles off.

Cheers

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland