Scala 2.9.x's problems with the DalvikVM

Hi,
> [3]https://gist.github.com/1214972
I wonder why scalac generates an anonymous class for every single method
in TraversableOnce/StreamViewLike ...

Bye,

Simon

Very many thanks for your work on this, Johannes.

I certainly hope that at some point these restrictions will be lifted in Android (I know that the Clojure community is butting up against the same limitations at the moment). But having said that:

On 13 Sep 2011, at 21:39, Johannes Rudolph wrote:
> * Try to reduce the footprint (of the most common parts) of the Scala library
> * Find out why proguard can't shrink Scala's library further into
> better consumable bits
> * Create a more lightweight Scala library for Android development

One or more of these options, it strikes me, definitely has to be part of the solution. Resource constrained devices are going to be with us for some time, and if Scala can't sensibly address them, that's going to be a very significant chink in its armour.

We currently use Scala very heavily on Android, but at the moment only for test code, not production. I was hoping that we were getting close to the point where that could change, but unfortunately the opposite seems to be true :-(

Anyway, thanks again for your efforts!

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul [at] paulbutcher [dot] com
AIM: paulrabutcher
Skype: paulrabutcher

One thing we should also try to find out is a summary of bugs that are
already opened against Android, that address these issues and if we
find some that are not adressed we should open the bug.

-
Stefan

2011/9/14 Paul Butcher :
> Very many thanks for your work on this, Johannes.
>
> I certainly hope that at some point these restrictions will be lifted in Android (I know that the Clojure community is butting up against the same limitations at the moment). But having said that:
>
> On 13 Sep 2011, at 21:39, Johannes Rudolph wrote:
>> * Try to reduce the footprint (of the most common parts) of the Scala library
>> * Find out why proguard can't shrink Scala's library further into
>> better consumable bits
>> * Create a more lightweight Scala library for Android development
>
>
> One or more of these options, it strikes me, definitely has to be part of the solution. Resource constrained devices are going to be with us for some time, and if Scala can't sensibly address them, that's going to be a very significant chink in its armour.
>
> We currently use Scala very heavily on Android, but at the moment only for test code, not production. I was hoping that we were getting close to the point where that could change, but unfortunately the opposite seems to be true :-(
>
> Anyway, thanks again for your efforts!
>
> --
> paul.butcher->msgCount++
>
> Snetterton, Castle Combe, Cadwell Park...
> Who says I have a one track mind?
>
> http://www.paulbutcher.com/
> LinkedIn: http://www.linkedin.com/in/paulbutcher
> MSN: paul [at] paulbutcher [dot] com
> AIM: paulrabutcher
> Skype: paulrabutcher
>
>

Unfortunately, somehow I saw this problem when using Scala 2.8.  It's a moderately sized application, and I got the problem when adding a single Scala class to the project.  Has anyone seen this problem in Scala 2.8?

On Sep 14, 7:20 am, Paul Butcher

wrote:
> I certainly hope that at some point these restrictions will be lifted inAndroid(I know that the Clojure community is butting up against the same limitations at the moment)....
> One or more of these options, it strikes me, definitely has to be part of the solution. Resource constrained devices are going to be with us for some time, and if Scala can't sensibly address them, that's going to be a very significant chink in its armour.

I think that it's unlikely to be usefully fixed on the Android side in
any kind of reasonable timeframe. Since it didn't happen for ICS last
night (at least as far as I can tell), that means you're probably
stuck with the limit for at least another year for brand-new devices.
And 4.0 devices will be around for a while, so if you want any sort of
market coverage, you're looking at multiple years before any Android
change makes a difference.

But like you said, if Scala just can't do small devices that's a real
problem. 6 megs of libraries for anything past 'hello world' isn't
really workable.

What kind of priority does fixing this have in the scala dev world?
I'd like to start doing Scala + Android (and just found the
https://groups.google.com/forum/#!forum/scala-on-android google
group), but it's unclear what kind of priority these issues have.

This could probably be fixed--albeit with a performance penalty--fairly quickly by compiling the library with specialization turned off.

On Wed, Oct 19, 2011 at 12:33 PM, James Moore <james [at] banshee [dot] com> wrote:

On Sep 14, 7:20 am, Paul Butcher <p [dot] [dot] [dot] [at] paulbutcher [dot] com> wrote:
> I certainly hope that at some point these restrictions will be lifted inAndroid(I know that the Clojure community is butting up against the same limitations at the moment)....
> One or more of these options, it strikes me, definitely has to be part of the solution. Resource constrained devices are going to be with us for some time, and if Scala can't sensibly address them, that's going to be a very significant chink in its armour.

I think that it's unlikely to be usefully fixed on the Android side in
any kind of reasonable timeframe.  Since it didn't happen for ICS last
night (at least as far as I can tell), that means you're probably
stuck with the limit for at least another year for brand-new devices.
And 4.0 devices will be around for a while, so if you want any sort of
market coverage, you're looking at multiple years before any Android
change makes a difference.

But like you said, if Scala just can't do small devices that's a real
problem.  6 megs of libraries for anything past 'hello world' isn't
really workable.

What kind of priority does fixing this have in the scala dev world?
I'd like to start doing Scala + Android (and just found the
https://groups.google.com/forum/#!forum/scala-on-android google
group), but it's unclear what kind of priority these issues have.

On Wed, Oct 19, 2011 at 6:46 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:

This could probably be fixed--albeit with a performance penalty--fairly quickly by compiling the library with specialization turned off.

I'd be interested in an experiment to see if it was true. If yes, we might want to ship with an alternate "slim" library for Android.

Cheers

 -- Martin

On Wed, Oct 19, 2011 at 12:33 PM, James Moore <james [at] banshee [dot] com> wrote:

On Sep 14, 7:20 am, Paul Butcher <p [dot] [dot] [dot] [at] paulbutcher [dot] com> wrote:
> I certainly hope that at some point these restrictions will be lifted inAndroid(I know that the Clojure community is butting up against the same limitations at the moment)....
> One or more of these options, it strikes me, definitely has to be part of the solution. Resource constrained devices are going to be with us for some time, and if Scala can't sensibly address them, that's going to be a very significant chink in its armour.

I think that it's unlikely to be usefully fixed on the Android side in
any kind of reasonable timeframe.  Since it didn't happen for ICS last
night (at least as far as I can tell), that means you're probably
stuck with the limit for at least another year for brand-new devices.
And 4.0 devices will be around for a while, so if you want any sort of
market coverage, you're looking at multiple years before any Android
change makes a difference.

But like you said, if Scala just can't do small devices that's a real
problem.  6 megs of libraries for anything past 'hello world' isn't
really workable.

What kind of priority does fixing this have in the scala dev world?
I'd like to start doing Scala + Android (and just found the
https://groups.google.com/forum/#!forum/scala-on-android google
group), but it's unclear what kind of priority these issues have.

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

On 19 Oct 2011, at 17:50, martin odersky wrote:

On Wed, Oct 19, 2011 at 6:46 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:

This could probably be fixed--albeit with a performance penalty--fairly quickly by compiling the library with specialization turned off.

I'd be interested in an experiment to see if it was true. If yes, we might want to ship with an alternate "slim" library for Android.

This would be great if it was a quick win :-)
Any feeling for how severe the performance penalty might be?
--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul [at] paulbutcher [dot] com
AIM: paulrabutcher
Skype: paulrabutcher

On Wed, Oct 19, 2011 at 6:46 PM, Rex Kerr wrote:
> This could probably be fixed--albeit with a performance penalty--fairly
> quickly by compiling the library with specialization turned off.

What makes you think so? Looking at the dump from my original post, my
greatest hopes right now are that (if there's a "quick fix") the
proposed changes to the view hierarchy could improve things quite a
lot.

It was a guess based upon specialization being responsible for much of the increase in size of the library, but those classes seem to have been fairly effectively removed from the set included in the jar.  What I don't know is whether there is any / enough of a static size penalty--even if the specialized classes aren't there--to make a difference.  I have anecdotal evidence for both "no" and "yes", and haven't tested carefully.

  --Rex

On Wed, Oct 19, 2011 at 1:05 PM, Johannes Rudolph <johannes [dot] rudolph [at] googlemail [dot] com> wrote:

On Wed, Oct 19, 2011 at 6:46 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
> This could probably be fixed--albeit with a performance penalty--fairly
> quickly by compiling the library with specialization turned off.

What makes you think so? Looking at the dump from my original post, my
greatest hopes right now are that (if there's a "quick fix") the
proposed changes to the view hierarchy could improve things quite a
lot.

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

Just in case this helps, compiling the scala lib sources with -no-specialization and -sourcepath results in jar size close to 6MB instead of the usual 8MB resulting from using specialization (the default) and -optimize (which inlines methods and thus in general increases size).

A further reduction should be possible by leaving out all parallel collection classes, which don't seem necessary on Android (if I remember correctly, Scala+GWT has a source-level conversion utility based on jdk2ikvm [1] to perform just that). Details in the Scala+GWT google group (I guess).

Another round of size reduction could result from "modularizing the Scala library".
  (a) In the Java world, a big jar file can be broken up into several smaller ones using tools like [2].
  (b) Two modularization efforts:
         https://github.com/scala-incubator/modularisation
         and
         https://github.com/paulp/scala-modular

Miguel
http://lamp.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/


References

[1] http://lamp.epfl.ch/~magarcia/jdk2ikvm/

[2] http://www.kirkk.com/main/Main/JarAnalyzer

"leaving out all parallel collection classes, which don't seem necessary on Android"
Except by 2013 when these devices will have a half dozen ARMs or double that.
The Scala compiler folks should just avoid targeting Android devices for production apps in 2012. Yes, shrink the footprint, etc. But prioritize your overall roadmap, and realize that Android devices will meet you more than half way by the time you are production-ready.
You cannot boil the ocean. The ocean's temperature is increasing... it will rise up to meet you.
Oh. Bad analogy.
-Patrick

Hi Miguel,

Did you try a recent version?
The file size of the standard jar is now at 6.8 MB here (2.10.0.r26094-b20111201023257).

How much reduction is still needed?

Thanks and bye,

Simon

Simon,

The jar comparison I made wasn't very scientific (I just compared lib/scala-library.jar with some version I compiled). In any case, my suggestion was mostly about trying in order (1) -no-specialization, (2) no parallel collections, (3) breaking the library into manageable chunks; before trying extending the compiler to target Dalvik (which can also be done).

Miguel
http://lamp.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/

On Sun, Dec 4, 2011 at 12:04 PM, Simon Ochsenreither
wrote:
> Hi Miguel,
>
> Did you try a recent version?
> The file size of the standard jar is now at 6.8 MB here
> (2.10.0.r26094-b20111201023257).
>
> How much reduction is still needed?

The critical metric isn't size, it's call sites. No more than 64k
(method definitions) + (calls to methods) is allowed.

Smaller is better, obviously, but I don't think size is the blocking
problem right now.

I wish that that was true. Unfortunately I fear that the limit is built into the fabric of the Dalvik VM as it currently stands and is unlikely to go away any time soon :-(

On 4 Dec 2011, at 18:03, Patrick Logan wrote:
> "leaving out all parallel collection classes, which don't seem necessary on Android"
>
> Except by 2013 when these devices will have a half dozen ARMs or double that.
>
> The Scala compiler folks should just avoid targeting Android devices for production apps in 2012. Yes, shrink the footprint, etc. But prioritize your overall roadmap, and realize that Android devices will meet you more than half way by the time you are production-ready.
>
> You cannot boil the ocean. The ocean's temperature is increasing... it will rise up to meet you.
>
> Oh. Bad analogy.
>
> -Patrick
>

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul [at] paulbutcher [dot] com
AIM: paulrabutcher
Skype: paulrabutcher

Is there a bug filed in Android's bug tracker?

Would make sense to make some noise there. Probably together with other languages which might have the same problem...

With more and more traffic on this topic, here's a follow-up on my
findings on some of the points:

On Tue, Sep 13, 2011 at 10:39 PM, Johannes Rudolph
wrote:
>  * Find out which classes exactly cause the problem, and how big the
> memory would have to be to support Scala

To find out how much memory would be needed I compiled a dalvik
version with increased LinearAlloc size. The example from the ticket
[1] would need a LinearAlloc size of about 10 MB (twice the current
size).

Then I checked what exactly needs those MBs of memory and I think I've
pretty much identified the current problem with the DalvikVM. See this
snippet (https://gist.github.com/1426684), which collects all of the
interfaces a class implements in a naive way:

scala> import collection.JavaConversions._
import collection.JavaConversions._

scala> def allIf(clazz: Class[_]): Seq[String] =
clazz.getInterfaces.map(_.toString) ++
clazz.getInterfaces.flatMap(allIf)
allIf: (clazz: Class[_])Seq[String]

scala> val theClazz =
Class.forName("scala.collection.immutable.StreamViewLike$$anon$10")
theClazz: Class[_] = class scala.collection.immutable.StreamViewLike$$anon$10

scala> val res0 = { allIf(theClazz) }
res0: Seq[String] = ...
scala> res0.size
res16: Int = 9223

scala> res0.distinct.size
res17: Int = 49

9223 ?!? What you see is multiple interface inheritance at work.
Unfortunately, the `allIf` function roughly corresponds to the way the
dalvik vm currently collects the full set of interfaces a
class/interface implements. The problem is that the DalvikVM doesn't
remove the duplicate interfaces in a final step (there was code to do
that, but is currently commented for some problems with other
functionality). Each interface needs at least 8 bytes of memory and
this is only one of the problematic classes. I guess this was never
better optimized because an interface hierarchy as complicated as this
is unusual in Java. I attached the hierarchy of the given class
(without ScalaObject) for illustration.

The question is if there is anything on the Scala side which would
improve the situation. The change of providing abstract classes for
some of the classes in the hierarchy didn't do much good here
unfortunately (because overall the hierarchy itself didn't change
much).

But there is something simple which could be done: There are a lot of
useless interface declarations which are already covered by super
interfaces. Most obvious example is ScalaObject which is a super
interface of all those interfaces. Removing all those interfaces would
mean a reduction to approx. 2000 interfaces for this example (but less
for other less spectacular cases).

>  * Try to use multiple class loaders to have multiple allocation regions of 5 MB

That won't work, there is some code which looks as if each ClassLoader
would be getting its own region of 5MB but in reality this is not
(yet?) implemented in dalvik.

>  * Find out why proguard can't shrink Scala's library further into better consumable bits

If you think about how shrinking works, you can quite easily see that
finding the minimal set of classes/methods needed for execution is
undecidable in theory (if you can't say for sure that a program halts,
neither you can say - for some points in the program - that those
points will be reached, so you can't prune from there on). In practice
you would have to optimistically include this code but this may be not
the biggest problem (because common programs may be sufficiently
simple). What is really hard, is handling virtual calls. As long as
you can't be sure what exactly the receiver of a virtual call is you
would have to include all possible subclasses. Now think about what
this means if you use Scala's Function classes. I think his explains
why proguard has problems with the highly inter-dependent collection
classes. There's academic literature on this topic, so maybe there is
a good enough solution which just no one has implemented for Java
bytecode.

Imho there seem to be ways to make it less worse than it currently is, imho the Android team should really fix this problem.

Did you create an issue/comment somewhere?

There was an Android bug filed in March 2010.  The present status is "working as intended."  Star it and add your feedback.

That's not the same as the current bug.

On Mon, Dec 5, 2011 at 3:44 PM, Glenview Jeff wrote:
> There was an Android bug filed in March 2010.  The present status is
> "working as intended."  Star it and add your feedback.

On Mon, Dec 5, 2011 at 4:01 AM, Simon Ochsenreither
wrote:
> Is there a bug filed in Android's bug tracker?
>
> Would make sense to make some noise there. Probably together with other
> languages which might have the same problem...

I don't know a bug number, but they're aware of the issue. When I
talked to some Dalvik guys at Google IO this year, they knew it was an
issue for scala, and thought that scala was an indicator that other
people would be hitting it too ("canary in the coal mine" was the
phrase used). They wanted to change it, but didn't have any
dates/releases for when that might happen.

On Mon, Dec 5, 2011 at 5:22 AM, Johannes Rudolph
wrote:
> scala> val res0 = { allIf(theClazz) }
> res0: Seq[String] = ...
> scala> res0.size
> res16: Int = 9223
>
> scala> res0.distinct.size
> res17: Int = 49
>
> 9223 ?!? What you see is multiple interface inheritance at work.

The interface minimization is checked in; the above now produces

scala> res0.size
res2: Int = 2351

scala> res0.distinct.size
res3: Int = 49

Attached is the bytecode diff before and after that change, if
anyone's interested.

Admittedly 2351 is still rather a large number. Here's the breakdown.

(interface scala.ScalaObject,634)
(interface scala.collection.GenTraversableOnce,263)
(interface scala.collection.Parallelizable,233)
(interface scala.collection.GenTraversableLike,233)
(interface scala.collection.generic.HasNewBuilder,156)
(interface scala.collection.generic.GenericTraversableTemplate,126)
(interface scala.collection.GenTraversable,126)
(interface scala.collection.GenIterableLike,77)
(interface scala.collection.GenTraversableViewLike,58)
(interface scala.collection.GenIterable,50)
(interface scala.collection.GenTraversableView,49)
(interface scala.collection.TraversableLike,30)
(interface scala.collection.generic.FilterMonadic,30)
(interface scala.collection.TraversableOnce,30)
(interface scala.collection.GenIterableViewLike,29)
(interface scala.Equals,27)
(interface scala.collection.GenIterableView,23)
(interface scala.collection.Traversable,18)
(interface scala.collection.GenSeqLike,15)
(interface scala.collection.GenSeq,12)
(interface scala.collection.IterableLike,12)
(interface scala.collection.GenTraversableViewLike$Transformed,11)
(interface scala.collection.Iterable,9)
(interface scala.collection.GenSeqViewLike,9)
(interface scala.collection.TraversableViewLike,9)
(interface scala.collection.TraversableView,9)
(interface scala.collection.ViewMkString,9)
(interface scala.collection.GenIterableViewLike$Transformed,8)
(interface scala.collection.IterableViewLike,6)
(interface scala.collection.GenSeqView,6)
(interface scala.collection.IterableView,6)
(interface scala.collection.GenSeqViewLike$Transformed,3)
(interface scala.Function1,3)
(interface scala.collection.SeqView,3)
(interface scala.collection.Seq,3)
(interface scala.collection.IterableViewLike$Transformed,3)
(interface scala.collection.SeqLike,3)
(interface scala.collection.TraversableViewLike$Transformed,3)
(interface scala.collection.SeqViewLike,3)
(interface scala.PartialFunction,3)
(interface scala.collection.SeqViewLike$Transformed,2)
(interface scala.collection.GenIterableViewLike$ZippedAll,2)
(interface scala.collection.immutable.StreamViewLike,1)
(interface scala.collection.immutable.StreamViewLike$ZippedAll,1)
(interface scala.collection.SeqViewLike$ZippedAll,1)
(interface scala.collection.GenSeqViewLike$ZippedAll,1)
(interface scala.collection.IterableViewLike$ZippedAll,1)
(interface scala.collection.immutable.StreamView,1)
(interface scala.collection.immutable.StreamViewLike$Transformed,1)

Unless I'm misunderstanding something here, in the bug report, danfuzz (presumably at Google) wrote:

I'm marking this as "working as intended," but that's really not the whole story:

It turns out that you have made the first report we've seen of anyone running into Dalvik's existing limit of 
65536 method references per dex file.

In the short term, we are going to fix the error message to be less opaque. In the long term, we will do a rev of 
the format to allow for "jumbo" method references (and field references, while we're at it). We knew we were 
seeing string counts approaching the 16-bit limit before we shipped 1.0, and so we introduced the const-
string/jumbo variant of the const-string opcode. However, we didn't think we'd see method counts hit the 
limit for quite a while. You have made us rethink our timeline!

As you noticed, by splitting your output into multiple dex files, you are neatly working around the problem. 
You will of course have a bit more to do to make multiple dex files work as part of an Android application, but 
all the right Android/Dalvik library support should be there for you to do that.

Thanks for the report, and I'm sorry that I can't promise a quick solution to the problem, as an executable 
format rev is no small matter.

On Monday, December 5, 2011 8:50:58 AM UTC-6, Johannes Rudolph wrote:

That's not the same as the current bug.

On Mon, Dec 5, 2011 at 3:44 PM, Glenview Jeff <glenvi [dot] [dot] [dot] [at] gmail [dot] com> wrote:
> There was an Android bug filed in March 2010.  The present status is
> "working as intended."  Star it and add your feedback.

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

On Mon, Dec 5, 2011 at 5:42 PM, Glenview Jeff wrote:
> Unless I'm misunderstanding something here, in the bug report, danfuzz
> (presumably at Google) wrote:

Oh, I didn't want to dispute that this may be still an issue, it's
just not the current blocker. At least not the one I'm seeing here. Is
anyone else still blocked by the bug from the issue?

On Mon, Dec 5, 2011 at 8:42 AM, Glenview Jeff <glenviewjeff [at] gmail [dot] com> wrote:

danfuzz (presumably at Google)

Dan is the creator and main architect of Dalvik.
-- Cédric

On Monday, December 5, 2011 12:10:17 PM UTC-6, Cédric Beust ♔ wrote:

Dan is the creator and main architect of Dalvik.

 If anybody is interested, he said he no longer works at Google or on Android.  He responded to my inquiry today about issue 7147.

Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;}

Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;}

I don't know: I left Google and stopped working on Android a couple months ago...You've always been able to load additional dex files into an app. I don't deny that it's extra effort in the build system and to put together the app bootstrap code, but it only has to be set up once for the entire Scala community.

 

For your delight (and awaiting your votes), here's the Android bug report

http://code.google.com/p/android/issues/detail?id=22586

Actually, the Android code once contained a fix for this issue which
was commented out later on. However, I think the reason why the old
fix had to be inactivated is invalid and then I went on and fixed the
issue blocking this one as well, so we might have good luck and have
this problem fixed in dalvik before 2015.

And BTW: you may find it interesting to know that you can produce the
same kind of problem with a 50-line Java file:

https://gist.github.com/1434551#file_src%2Ftest.java

On Mon, Dec 5, 2011 at 10:06 PM, Johannes Rudolph
wrote:
> For your delight (and awaiting your votes), here's the Android bug report
>
> http://code.google.com/p/android/issues/detail?id=22586
>
> Actually, the Android code once contained a fix for this issue which
> was commented out later on. However, I think the reason why the old
> fix had to be inactivated is invalid and then I went on and fixed the
> issue blocking this one as well, so we might have good luck and have
> this problem fixed in dalvik before 2015.
>
>
> --
> Johannes
>
> -----------------------------------------------
> Johannes Rudolph
> http://virtual-void.net

Thank you very much for your work!

I don't know a bug number, but they're aware of the issue. 

One of the limits is discussed here: http://code.google.com/p/android/issues/detail?id=7147 

BTW, thanks for the effort here, it's much appreciated. I did one
superficial test with a SNAPSHOT version last week, and unfortunately
it still isn't working. I had no time yet to rerun with my customized
dalvik version to check how much things have improved exactly and
what's still missing. (Not every day is the right day to get your
mobile phone out of the continuous reboot loop caused by a broken
dalvikvm...)

On Mon, Dec 5, 2011 at 5:20 PM, Paul Phillips wrote:
> On Mon, Dec 5, 2011 at 5:22 AM, Johannes Rudolph
> wrote:
>> scala> val res0 = { allIf(theClazz) }
>> res0: Seq[String] = ...
>> scala> res0.size
>> res16: Int = 9223
>>
>> scala> res0.distinct.size
>> res17: Int = 49
>>
>> 9223 ?!? What you see is multiple interface inheritance at work.
>
> The interface minimization is checked in; the above now produces
>
> scala> res0.size
> res2: Int = 2351
>
> scala> res0.distinct.size
> res3: Int = 49

Is there any progress with issue? I am greatly interested in it. I modified createramdisks scripts from github.com/jberkel/android-sdk-scala so that able to preload scala-library (any version and other java libraries) to emulator withing seconds. This is significant reduce build process. Libraries load to /data and security descriptors to /system/etc/permission. Rooted phone is unnecessary.
Also that way allow to get error only when library used, not at boot stage. But unfortunately there is always sporadically with any scala versions, 2.8 too :-(

E/dalvikvm(  787): LinearAlloc exceeded capacity (5242880), last=19092
E/dalvikvm(  787): VM aborting
I/DEBUG   (   31): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   (   31): Build fingerprint: 'generic/sdk/generic/:2.2/FRF91/43546:eng/test-keys'
I/DEBUG   (   31): pid: 787, tid: 787  >>> org.digimead.digi.inetd.sshd <<<
or something like this for any significant code. So sad.
I am sure that the only right way is to run scala-test suite at android emulator. If scala-test compiller suite pass without any errors than scala ready for tablet devices. Maybe to write android activity, that allow to run scala-test suite in adb shell? But without support from scala core developers – it will be useless.

PS “As of December 2011 there are over 700,000 Android devices activated every day.” It is very disappoint that scala developers ignore such part of market and build compiler in unportable way, that allow to use cross platform language only at limited number of targets.

PPS I may share my scripts that allow preload java(scala) libraries at emulator. Also I am ready to help with it, but I am afraid that my knowledge a bit limited.

King regards,
Alexey

Have you've checked the latest Scala version from master?

On Thu, Jan 5, 2012 at 8:33 PM, Alexey Aksenov <alexey [dot] ezh [at] gmail [dot] com> wrote:

Is there any progress with issue? I am greatly interested in it. I modified createramdisks scripts from github.com/jberkel/android-sdk-scala so that able to preload scala-library (any version and other java libraries) to emulator withing seconds. This is significant reduce build process. Libraries load to /data and security descriptors to /system/etc/permission. Rooted phone is unnecessary.
Also that way allow to get error only when library used, not at boot stage. But unfortunately there is always sporadically with any scala versions, 2.8 too :-(

E/dalvikvm(  787): LinearAlloc exceeded capacity (5242880), last=19092
E/dalvikvm(  787): VM aborting
I/DEBUG   (   31): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   (   31): Build fingerprint: 'generic/sdk/generic/:2.2/FRF91/43546:eng/test-keys'
I/DEBUG   (   31): pid: 787, tid: 787  >>> org.digimead.digi.inetd.sshd <<<
or something like this for any significant code. So sad.
I am sure that the only right way is to run scala-test suite at android emulator. If scala-test compiller suite pass without any errors than scala ready for tablet devices. Maybe to write android activity, that allow to run scala-test suite in adb shell? But without support from scala core developers – it will be useless.

PS “As of December 2011 there are over 700,000 Android devices activated every day.” It is very disappoint that scala developers ignore such part of market and build compiler in unportable way, that allow to use cross platform language only at limited number of targets.

PPS I may share my scripts that allow preload java(scala) libraries at emulator. Also I am ready to help with it, but I am afraid that my knowledge a bit limited.

King regards,
Alexey

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

On Thu, Jan 5, 2012 at 11:33 AM, Alexey Aksenov <alexey [dot] ezh [at] gmail [dot] com> wrote:

If scala-test compiller suite pass without any errors than scala ready for tablet devices. Maybe to write android activity, that allow to run scala-test suite in adb shell? But without support from scala core developers – it will be useless.

What kind of support do you have in mind? I can't do the work, but I support the goal. 

PS “As of December 2011 there are over 700,000 Android devices activated every day.” It is very disappoint that scala developers ignore such part of market and build compiler in unportable way, that allow to use cross platform language only at limited number of targets.

Personally I'm not ignoring it, but I have to choose my battles.  Take a look at the bug database sometime and then try to tell me I can work on android-specific matters in good conscience.

Thank you all for answer. I was afraid that there is not activity and
interested in solve.

Ok. I did test. What's next?

download latest with git clone https://github.com/scala/scala.git
compile with and fastdist
upload
Scala code runner version 2.10.0.rdev-4118-2012-01-05-gbe46e48 --
Copyright 2002-2011, LAMP/EPFL

Using Scala in /home/ezh/.sbt/boot/scala-2.10.0-SNAPSHOT

Generating scala-library.jar...

Generating scala-collection.jar...

Generating scala-immutable.jar...

Generating scala-mutable.jar...

Generating scala-actors.jar...

Converting scala-library.jar into a dex file...

Converting scala-collection.jar into a dex file...

Converting scala-immutable.jar into a dex file...

Converting scala-mutable.jar into a dex file...

Converting scala-actors.jar into a dex file...

Dex files were successfully generated (configs/framework)

recompile my project with sbt

and :-( other error, scala broken at thunk? Libraries loaded
successful.
Log strings like «D/o.d.d.i.s*.SSHDActivity( 282): alive
» generated with "org.slf4j" % "slf4j-android" % "1.6.1-RC1" FYI
Proguard disabled. Only plain preloaded libraries... How may I fix
this issue? I may connect debugger from eclipse within one moment. But
where to look?

org.digimead.digi.inetd.sshd.SSHDActivity.onResume(SSHDActivity.scala:
94)
is
override def onResume() {

log.debug("onResume(...)")

super.onResume()

if (sshdService.get() == null)

94!!!!: future { bindService(new Intent(this,
classOf[SSHDService]), sshdConnection, Context.BIND_AUTO_CREATE) }

registerReceiver(receiver, new
IntentFilter(SSHDService.updateIntent))

}

I/ActivityManager( 59): Starting activity: Intent
{ act=android.intent.action.MAIN
cat=[android.intent.category.LAUNCHER] flg=0x10200000
cmp=org.digimead.digi.inetd.sshd/.SSHDActivity }

I/ActivityManager( 59): Start proc org.digimead.digi.inetd.sshd for
activity org.digimead.digi.inetd.sshd/.SSHDActivity: pid=282 uid=10036
gids={}

I/ARMAssembler( 59): generated
scanline__00000077:03545404_00000004_00000000 [ 47 ipp] (67 ins) at
[0x359058:0x359164] in 264230 ns

I/AndroidLoggerFactory( 282): Logger name 'o.d.d.i.sshd.SSHDActivity'
exceeds maximum length of 23 characters, using
'o.d.d.i.s*.SSHDActivity' instead.

D/o.d.d.i.s*.SSHDActivity( 282): alive

D/o.d.d.i.s*.SSHDActivity( 282): onCreate(...)

I/AndroidLoggerFactory( 282): Logger name
'o.d.d.i.sshd.service.TabActivity' exceeds maximum length of 23
characters, using 'o.d.d.i.s*.s*.TabActiv*' instead.

D/dalvikvm( 282): GC_FOR_MALLOC freed 3891 objects / 370824 bytes in
34ms

D/dalvikvm( 282): GC_FOR_MALLOC freed 3838 objects / 444456 bytes in
39ms

D/dalvikvm( 282): GC_EXTERNAL_ALLOC freed 80 objects / 5008 bytes in
30ms

I/AndroidLoggerFactory( 282): Logger name
'o.d.d.i.sshd.info.TabActivity' exceeds maximum length of 23
characters, using 'o.d.d.i.s*.i*.TabActiv*' instead.

D/o.d.d.i.s*.SSHDActivity( 282): onStart(...)

D/o.d.d.i.s*.SSHDActivity( 282): onResume(...)

I/dalvikvm( 282): Could not find method
scala.actors.IScheduler.getClass, referenced from method
scala.actors.scheduler.DaemonScheduler$.makeNewScheduler

W/dalvikvm( 282): VFY: unable to resolve interface method 1527:
Lscala/actors/IScheduler;.getClass ()Ljava/lang/Class;

D/dalvikvm( 282): VFY: replacing opcode 0x72 at 0x0032

D/dalvikvm( 282): VFY: dead code 0x0035-0047 in Lscala/actors/
scheduler/DaemonScheduler$;.makeNewScheduler ()Lscala/actors/
IScheduler;

I/dalvikvm( 282): Could not find method
scala.actors.IScheduler.getClass, referenced from method
scala.actors.Reactor$$anon$2.makeNewScheduler

W/dalvikvm( 282): VFY: unable to resolve interface method 1527:
Lscala/actors/IScheduler;.getClass ()Ljava/lang/Class;

D/dalvikvm( 282): VFY: replacing opcode 0x72 at 0x003f

D/dalvikvm( 282): VFY: dead code 0x0042-0054 in Lscala/actors/Reactor$
$anon$2;.makeNewScheduler ()Lscala/actors/IScheduler;

I/dalvikvm( 282): Could not find method scala.actors.Actor.wait,
referenced from method scala.actors.Actor$class.liftedTree1$1

W/dalvikvm( 282): VFY: unable to resolve interface method 1021:
Lscala/actors/Actor;.wait ()V

D/dalvikvm( 282): VFY: replacing opcode 0x72 at 0x0000

I/dalvikvm( 282): Could not find method scala.actors.Actor.notify,
referenced from method scala.actors.Actor$class.scala$actors$Actor$
$resumeActor

W/dalvikvm( 282): VFY: unable to resolve interface method 982: Lscala/
actors/Actor;.notify ()V

D/dalvikvm( 282): VFY: replacing opcode 0x72 at 0x0004

D/dalvikvm( 282): VFY: dead code 0x0007-0007 in Lscala/actors/Actor
$class;.scala$actors$Actor$$resumeActor (Lscala/actors/Actor;)V

D/AndroidRuntime( 282): Shutting down VM

W/dalvikvm( 282): threadid=1: thread exiting with uncaught exception
(group=0x4001d800)

E/AndroidRuntime( 282): FATAL EXCEPTION: main

E/AndroidRuntime( 282): java.lang.NoSuchMethodError:
scala.actors.IScheduler.getClass

E/AndroidRuntime( 282): at scala.actors.scheduler.DaemonScheduler
$.makeNewScheduler(DaemonScheduler.scala:29)

E/AndroidRuntime( 282): at scala.actors.scheduler.DelegatingScheduler
$class.newActor(DelegatingScheduler.scala:63)

E/AndroidRuntime( 282): at scala.actors.scheduler.DaemonScheduler
$.newActor(DaemonScheduler.scala:17)

E/AndroidRuntime( 282): at scala.actors.Reactor
$class.dostart(Reactor.scala:220)

E/AndroidRuntime( 282): at scala.actors.FutureActor.scala$actors
$Actor$$super$dostart(Future.scala:47)

E/AndroidRuntime( 282): at scala.actors.Actor
$class.dostart(Actor.scala:666)

E/AndroidRuntime( 282): at
scala.actors.FutureActor.dostart(Future.scala:47)

E/AndroidRuntime( 282): at scala.actors.Reactor
$class.start(Reactor.scala:229)

E/AndroidRuntime( 282): at scala.actors.FutureActor.scala$actors
$Actor$$super$start(Future.scala:47)

E/AndroidRuntime( 282): at scala.actors.Actor
$class.start(Actor.scala:670)

E/AndroidRuntime( 282): at
scala.actors.FutureActor.start(Future.scala:47)

E/AndroidRuntime( 282): at scala.actors.Futures$.future(Future.scala:
122)

E/AndroidRuntime( 282): at
org.digimead.digi.inetd.sshd.SSHDActivity.onResume(SSHDActivity.scala:
94)

E/AndroidRuntime( 282): at
android.app.Instrumentation.callActivityOnResume(Instrumentation.java:
1149)

E/AndroidRuntime( 282): at
android.app.Activity.performResume(Activity.java:3823)

E/AndroidRuntime( 282): at
android.app.ActivityThread.performResumeActivity(ActivityThread.java:
3118)

E/AndroidRuntime( 282): at
android.app.ActivityThread.handleResumeActivity(ActivityThread.java:
3143)

E/AndroidRuntime( 282): at
android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:
2684)

E/AndroidRuntime( 282): at android.app.ActivityThread.access
$2300(ActivityThread.java:125)

E/AndroidRuntime( 282): at android.app.ActivityThread
$H.handleMessage(ActivityThread.java:2033)

E/AndroidRuntime( 282): at
android.os.Handler.dispatchMessage(Handler.java:99)

E/AndroidRuntime( 282): at android.os.Looper.loop(Looper.java:123)

E/AndroidRuntime( 282): at
android.app.ActivityThread.main(ActivityThread.java:4627)

E/AndroidRuntime( 282): at
java.lang.reflect.Method.invokeNative(Native Method)

E/AndroidRuntime( 282): at
java.lang.reflect.Method.invoke(Method.java:521)

E/AndroidRuntime( 282): at com.android.internal.os.ZygoteInit
$MethodAndArgsCaller.run(ZygoteInit.java:868)

E/AndroidRuntime( 282): at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)

E/AndroidRuntime( 282): at dalvik.system.NativeStart.main(Native
Method)

On 5 янв, 23:40, √iktor Ҡlang wrote:
> Have you've checked the latest Scala version from master?
>
...

On Thu, Jan 5, 2012 at 12:28 PM, Alexey Aksenov <alexey [dot] ezh [at] gmail [dot] com> wrote:

I/dalvikvm(  282): Could not find method
scala.actors.IScheduler.getClass, referenced from method
scala.actors.scheduler.DaemonScheduler$.makeNewScheduler

W/dalvikvm(  282): VFY: unable to resolve interface method 1527:
Lscala/actors/IScheduler;.getClass ()Ljava/lang/Class;

That is a bug, we are apparently generating invokeinterface instructions for java.lang.Object methods when the target is an interface.  I don't think they're supposed to choke on it (don't interfaces inherit from Object?) but we should fix it regardless.

Ok, sure. I have git code. I may recompile scala library. I may run
and check it. But how may I help to fix this issue?

My own goal - successful launch simple as hello world program. What is
the next step? Open new issue? Or is it possible to solve this in this
mail thread? Please, help.

That kind of support I have in mind. There is a problem and I cannot
solve it alone :-(

I absolutely have no idea how handle:

> That is a bug, we are apparently generating invokeinterface instructions
> for java.lang.Object methods when the target is an interface. I don't
> think they're supposed to choke on it (don't interfaces inherit from
> Object?) but we should fix it regardless.

How "should I fix it regardless?" :-) My ability to knowledge
everything is a bit limited. I don't know internal mechanic of scala
compiler. But I may regardless if needed with help of someone.
So is it possible to fix in some test branch?
Could you provide me some tips with source file name, than probably
contain bug. I try to read a code.

> Paul Phillips
> On Thu, Jan 5, 2012 at 11:33 AM, Alexey Aksenov wrote:
>
>> If scala-test compiller suite pass without any errors than scala ready for
>> tablet devices. Maybe to write android activity, that allow to run
>> scala-test suite in adb shell? But without support from scala core
>> developers – it will be useless.
>
> What kind of support do you have in mind? I can't do the work, but I
> support the goal.

On 6 янв, 00:46, Paul Phillips wrote:
> On Thu, Jan 5, 2012 at 12:28 PM, Alexey Aksenov wrote:
>
> > I/dalvikvm(  282): Could not find method
> > scala.actors.IScheduler.getClass, referenced from method
> > scala.actors.scheduler.DaemonScheduler$.makeNewScheduler
>
> > W/dalvikvm(  282): VFY: unable to resolve interface method 1527:
> > Lscala/actors/IScheduler;.getClass ()Ljava/lang/Class;
>
> That is a bug, we are apparently generating invokeinterface instructions
> for java.lang.Object methods when the target is an interface.  I don't
> think they're supposed to choke on it (don't interfaces inherit from
> Object?) but we should fix it regardless.

On Thu, Jan 5, 2012 at 1:10 PM, Alexey Aksenov <alexey [dot] ezh [at] gmail [dot] com> wrote:

How "should I fix it regardless?" :-) My ability to knowledge
everything is a bit limited. I don't know internal mechanic of scala
compiler. But I may regardless if needed with help of someone.

I already fixed it, but for reference, the files most likely to be relevant to bytecode generation issues are:

http://github.com/scala/scala/tree/master/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala http://github.com/scala/scala/tree/master/src/compiler/scala/tools/nsc/backend/jvm/GenJVMUtil.scala
The change in this case:

diff --git a/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala b/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scalaindex 241163885d..c5624a86aa 100644 --- a/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala+++ b/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala@@ -1199,7 +1199,7 @@ abstract class GenJVM extends SubComponent with GenJVMUtil with GenAndroid with        hostSymbol.info ; methodOwner.info        def isInterfaceCall(sym: Symbol) = (-           sym.isInterface+           sym.isInterface && methodOwner != ObjectClass          || sym.isJavaDefined && sym.isNonBottomSubClass(ClassfileAnnotationClass)       )       // whether to reference the type of the receiver or

I am sorry

But I may _regardless if needed with help of someone.

actually

But I may _investigate if needed with help of someone.

On 6 янв, 01:10, Alexey Aksenov wrote:
> Ok, sure. I have git code. I may recompile scala library. I may run
> and check it. But how may I help to fix this issue?
>
> My own goal - successful launch simple as hello world program. What is
> the next step? Open new issue? Or is it possible to solve this in this
> mail thread? Please, help.
>
> That kind of support I have in mind. There is a problem and I cannot
> solve it alone :-(
>
> I absolutely have no idea how handle:
>
> > That is a bug, we are apparently generating invokeinterface instructions
> > for java.lang.Object methods when the target is an interface.  I don't
> > think they're supposed to choke on it (don't interfaces inherit from
> > Object?) but we should fix it regardless.
>
> How "should I fix it regardless?" :-) My ability to knowledge
> everything is a bit limited. I don't know internal mechanic of scala
> compiler. But I may regardless if needed with help of someone.
> So is it possible to fix in some test branch?
> Could you provide me some tips with source file name, than probably
> contain bug. I try to read a code.
>
> > Paul Phillips
> > On Thu, Jan 5, 2012 at 11:33 AM, Alexey Aksenov wrote:
>
> >> If scala-test compiller suite pass without any errors than scala ready for
> >> tablet devices. Maybe to write android activity, that allow to run
> >> scala-test suite in adb shell? But without support from scala core
> >> developers – it will be useless.
>
> > What kind of support do you have in mind? I can't do the work, but I
> > support the goal.
>
> On 6 янв, 00:46, Paul Phillips wrote:
>
>
>
>
>
>
>
> > On Thu, Jan 5, 2012 at 12:28 PM, Alexey Aksenov wrote:
>
> > > I/dalvikvm(  282): Could not find method
> > > scala.actors.IScheduler.getClass, referenced from method
> > > scala.actors.scheduler.DaemonScheduler$.makeNewScheduler
>
> > > W/dalvikvm(  282): VFY: unable to resolve interface method 1527:
> > > Lscala/actors/IScheduler;.getClass ()Ljava/lang/Class;
>
> > That is a bug, we are apparently generating invokeinterface instructions
> > for java.lang.Object methods when the target is an interface.  I don't
> > think they're supposed to choke on it (don't interfaces inherit from
> > Object?) but we should fix it regardless.

Unsuccessful. There was 2 attempt (I want to check that results are
the same)

Only difference is
unable to resolve interface method 1522 before
vs
unable to resolve interface method 1527 after

other numbers are same

I suspect that interface methods quantity changed: -5

Anything else?

PS Compiler code is too heavy for me. I think that I must spent a lot
of time (more than I have, I am afraid) to rich acceptable level of
knowledge for solve such type problems alone :-(

D/o.d.d.i.s*.SSHDActivity( 315): onResume(...)
I/dalvikvm( 315): Could not find method
scala.actors.IScheduler.getClass, referenced from method
scala.actors.scheduler.DaemonScheduler$.makeNewScheduler
W/dalvikvm( 315): VFY: unable to resolve interface method 1522:
Lscala/actors/IScheduler;.getClass ()Ljava/lang/Class;
D/dalvikvm( 315): VFY: replacing opcode 0x72 at 0x0032
D/dalvikvm( 315): VFY: dead code 0x0035-0047 in Lscala/actors/
scheduler/DaemonScheduler$;.makeNewScheduler ()Lscala/actors/
IScheduler;
I/dalvikvm( 315): Could not find method
scala.actors.IScheduler.getClass, referenced from method
scala.actors.Reactor$$anon$2.makeNewScheduler
W/dalvikvm( 315): VFY: unable to resolve interface method 1522:
Lscala/actors/IScheduler;.getClass ()Ljava/lang/Class;
D/dalvikvm( 315): VFY: replacing opcode 0x72 at 0x003f
D/dalvikvm( 315): VFY: dead code 0x0042-0054 in Lscala/actors/Reactor$
$anon$2;.makeNewScheduler ()Lscala/actors/IScheduler;
I/dalvikvm( 315): Could not find method scala.actors.Actor.wait,
referenced from method scala.actors.Actor$class.liftedTree1$1
W/dalvikvm( 315): VFY: unable to resolve interface method 1021:
Lscala/actors/Actor;.wait ()V
D/dalvikvm( 315): VFY: replacing opcode 0x72 at 0x0000
I/dalvikvm( 315): Could not find method scala.actors.Actor.notify,
referenced from method scala.actors.Actor$class.scala$actors$Actor$
$resumeActor
W/dalvikvm( 315): VFY: unable to resolve interface method 982: Lscala/
actors/Actor;.notify ()V
D/dalvikvm( 315): VFY: replacing opcode 0x72 at 0x0004
D/dalvikvm( 315): VFY: dead code 0x0007-0007 in Lscala/actors/Actor
$class;.scala$actors$Actor$$resumeActor (Lscala/actors/Actor;)V
D/AndroidRuntime( 315): Shutting down VM
W/dalvikvm( 315): threadid=1: thread exiting with uncaught exception
(group=0x4001d800)
E/AndroidRuntime( 315): FATAL EXCEPTION: main
E/AndroidRuntime( 315): java.lang.NoSuchMethodError:
scala.actors.IScheduler.getClass
E/AndroidRuntime( 315): at scala.actors.scheduler.DaemonScheduler
$.makeNewScheduler(DaemonScheduler.scala:29)
E/AndroidRuntime( 315): at scala.actors.scheduler.DelegatingScheduler
$class.newActor(DelegatingScheduler.scala:63)
E/AndroidRuntime( 315): at scala.actors.scheduler.DaemonScheduler
$.newActor(DaemonScheduler.scala:17)
E/AndroidRuntime( 315): at scala.actors.Reactor
$class.dostart(Reactor.scala:220)
E/AndroidRuntime( 315): at scala.actors.FutureActor.scala$actors
$Actor$$super$dostart(Future.scala:47)
E/AndroidRuntime( 315): at scala.actors.Actor
$class.dostart(Actor.scala:666)
E/AndroidRuntime( 315): at
scala.actors.FutureActor.dostart(Future.scala:47)
E/AndroidRuntime( 315): at scala.actors.Reactor
$class.start(Reactor.scala:229)
E/AndroidRuntime( 315): at scala.actors.FutureActor.scala$actors
$Actor$$super$start(Future.scala:47)
E/AndroidRuntime( 315): at scala.actors.Actor
$class.start(Actor.scala:670)
E/AndroidRuntime( 315): at
scala.actors.FutureActor.start(Future.scala:47)
E/AndroidRuntime( 315): at scala.actors.Futures$.future(Future.scala:
122)
E/AndroidRuntime( 315): at
org.digimead.digi.inetd.sshd.SSHDActivity.onResume(SSHDActivity.scala:
94)
E/AndroidRuntime( 315): at
android.app.Instrumentation.callActivityOnResume(Instrumentation.java:
1149)
E/AndroidRuntime( 315): at
android.app.Activity.performResume(Activity.java:3823)
E/AndroidRuntime( 315): at
android.app.ActivityThread.performResumeActivity(ActivityThread.java:
3118)
E/AndroidRuntime( 315): at
android.app.ActivityThread.handleResumeActivity(ActivityThread.java:
3143)
E/AndroidRuntime( 315): at
android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:
2684)
E/AndroidRuntime( 315): at android.app.ActivityThread.access
$2300(ActivityThread.java:125)
E/AndroidRuntime( 315): at android.app.ActivityThread
$H.handleMessage(ActivityThread.java:2033)
E/AndroidRuntime( 315): at
android.os.Handler.dispatchMessage(Handler.java:99)
E/AndroidRuntime( 315): at android.os.Looper.loop(Looper.java:123)
E/AndroidRuntime( 315): at
android.app.ActivityThread.main(ActivityThread.java:4627)
E/AndroidRuntime( 315): at
java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime( 315): at
java.lang.reflect.Method.invoke(Method.java:521)
E/AndroidRuntime( 315): at com.android.internal.os.ZygoteInit
$MethodAndArgsCaller.run(ZygoteInit.java:868)
E/AndroidRuntime( 315): at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)
E/AndroidRuntime( 315): at dalvik.system.NativeStart.main(Native
Method)

On 6 янв, 01:16, Paul Phillips wrote:
> On Thu, Jan 5, 2012 at 1:10 PM, Alexey Aksenov wrote:
> > How "should I fix it regardless?" :-) My ability to knowledge
> > everything is a bit limited. I don't know internal mechanic of scala
> > compiler. But I may regardless if needed with help of someone.
>
> I already fixed it, but for reference, the files most likely to be relevant
> to bytecode generation issues are:
>
> http://github.com/scala/scala/tree/master/src/compiler/scala/tools/ns.........
>
> The change in this case:
>
> diff --git a/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
> b/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
> index 241163885d..c5624a86aa 100644

Try to use reflection a bit with

classOf[scala.actors.IScheduler].getMethods().foreach(m =>
log.error(m.toString))

E/o.d.d.i.s*.SSHDActivity( 338): public abstract void
scala.actors.IScheduler.execute(java.lang.Runnable)
E/o.d.d.i.s*.SSHDActivity( 338): public abstract void
scala.actors.IScheduler.execute(scala.Function0)
E/o.d.d.i.s*.SSHDActivity( 338): public abstract void
scala.actors.IScheduler.executeFromActor(java.lang.Runnable)
E/o.d.d.i.s*.SSHDActivity( 338): public abstract boolean
scala.actors.IScheduler.isActive()
E/o.d.d.i.s*.SSHDActivity( 338): public abstract void
scala.actors.IScheduler.managedBlock(scala.concurrent.ManagedBlocker)
E/o.d.d.i.s*.SSHDActivity( 338): public abstract void
scala.actors.IScheduler.newActor(scala.actors.Reactor)
E/o.d.d.i.s*.SSHDActivity( 338): public abstract void
scala.actors.IScheduler.onTerminate(scala.actors.Reactor,scala.Function0)
E/o.d.d.i.s*.SSHDActivity( 338): public abstract void
scala.actors.IScheduler.shutdown()
E/o.d.d.i.s*.SSHDActivity( 338): public abstract void
scala.actors.IScheduler.terminated(scala.actors.Reactor)

On 6 янв, 02:04, Alexey Aksenov wrote:
> Unsuccessful. There was 2 attempt (I want to check that results are
> the same)
>
> Only difference is
> unable to resolve interface method 1522 before
> vs
> unable to resolve interface method 1527 after
>
> other numbers are same
>
> I suspect that interface methods quantity changed: -5
>
> Anything else?
>
> PS Compiler code is too heavy for me. I think that I must spent a lot
> of time (more than I have, I am afraid) to rich acceptable level of
> knowledge for solve such type problems alone :-(
>
> D/o.d.d.i.s*.SSHDActivity(  315): onResume(...)
> I/dalvikvm(  315): Could not find method
> scala.actors.IScheduler.getClass, referenced from method
> scala.actors.scheduler.DaemonScheduler$.makeNewScheduler
> W/dalvikvm(  315): VFY: unable to resolve interface method 1522:
> Lscala/actors/IScheduler;.getClass ()Ljava/lang/Class;
> D/dalvikvm(  315): VFY: replacing opcode 0x72 at 0x0032
> D/dalvikvm(  315): VFY: dead code 0x0035-0047 in Lscala/actors/
> scheduler/DaemonScheduler$;.makeNewScheduler ()Lscala/actors/
> IScheduler;
> I/dalvikvm(  315): Could not find method
> scala.actors.IScheduler.getClass, referenced from method
> scala.actors.Reactor$$anon$2.makeNewScheduler
> W/dalvikvm(  315): VFY: unable to resolve interface method 1522:
> Lscala/actors/IScheduler;.getClass ()Ljava/lang/Class;
> D/dalvikvm(  315): VFY: replacing opcode 0x72 at 0x003f
> D/dalvikvm(  315): VFY: dead code 0x0042-0054 in Lscala/actors/Reactor$
> $anon$2;.makeNewScheduler ()Lscala/actors/IScheduler;
> I/dalvikvm(  315): Could not find method scala.actors.Actor.wait,
> referenced from method scala.actors.Actor$class.liftedTree1$1
> W/dalvikvm(  315): VFY: unable to resolve interface method 1021:
> Lscala/actors/Actor;.wait ()V
> D/dalvikvm(  315): VFY: replacing opcode 0x72 at 0x0000
> I/dalvikvm(  315): Could not find method scala.actors.Actor.notify,
> referenced from method scala.actors.Actor$class.scala$actors$Actor$
> $resumeActor
> W/dalvikvm(  315): VFY: unable to resolve interface method 982: Lscala/
> actors/Actor;.notify ()V
> D/dalvikvm(  315): VFY: replacing opcode 0x72 at 0x0004
> D/dalvikvm(  315): VFY: dead code 0x0007-0007 in Lscala/actors/Actor
> $class;.scala$actors$Actor$$resumeActor (Lscala/actors/Actor;)V
> D/AndroidRuntime(  315): Shutting down VM
> W/dalvikvm(  315): threadid=1: thread exiting with uncaught exception
> (group=0x4001d800)
> E/AndroidRuntime(  315): FATAL EXCEPTION: main
> E/AndroidRuntime(  315): java.lang.NoSuchMethodError:
> scala.actors.IScheduler.getClass
> E/AndroidRuntime(  315):        at scala.actors.scheduler.DaemonScheduler
> $.makeNewScheduler(DaemonScheduler.scala:29)
> E/AndroidRuntime(  315):        at scala.actors.scheduler.DelegatingScheduler
> $class.newActor(DelegatingScheduler.scala:63)
> E/AndroidRuntime(  315):        at scala.actors.scheduler.DaemonScheduler
> $.newActor(DaemonScheduler.scala:17)
> E/AndroidRuntime(  315):        at scala.actors.Reactor
> $class.dostart(Reactor.scala:220)
> E/AndroidRuntime(  315):        at scala.actors.FutureActor.scala$actors
> $Actor$$super$dostart(Future.scala:47)
> E/AndroidRuntime(  315):        at scala.actors.Actor
> $class.dostart(Actor.scala:666)
> E/AndroidRuntime(  315):        at
> scala.actors.FutureActor.dostart(Future.scala:47)
> E/AndroidRuntime(  315):        at scala.actors.Reactor
> $class.start(Reactor.scala:229)
> E/AndroidRuntime(  315):        at scala.actors.FutureActor.scala$actors
> $Actor$$super$start(Future.scala:47)
> E/AndroidRuntime(  315):        at scala.actors.Actor
> $class.start(Actor.scala:670)
> E/AndroidRuntime(  315):        at
> scala.actors.FutureActor.start(Future.scala:47)
> E/AndroidRuntime(  315):        at scala.actors.Futures$.future(Future.scala:
> 122)
> E/AndroidRuntime(  315):        at
> org.digimead.digi.inetd.sshd.SSHDActivity.onResume(SSHDActivity.scala:
> 94)
> E/AndroidRuntime(  315):        at
> android.app.Instrumentation.callActivityOnResume(Instrumentation.java:
> 1149)
> E/AndroidRuntime(  315):        at
> android.app.Activity.performResume(Activity.java:3823)
> E/AndroidRuntime(  315):        at
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:
> 3118)
> E/AndroidRuntime(  315):        at
> android.app.ActivityThread.handleResumeActivity(ActivityThread.java:
> 3143)
> E/AndroidRuntime(  315):        at
> android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:
> 2684)
> E/AndroidRuntime(  315):        at android.app.ActivityThread.access
> $2300(ActivityThread.java:125)
> E/AndroidRuntime(  315):        at android.app.ActivityThread
> $H.handleMessage(ActivityThread.java:2033)
> E/AndroidRuntime(  315):        at
> android.os.Handler.dispatchMessage(Handler.java:99)
> E/AndroidRuntime(  315):        at android.os.Looper.loop(Looper.java:123)
> E/AndroidRuntime(  315):        at
> android.app.ActivityThread.main(ActivityThread.java:4627)
> E/AndroidRuntime(  315):        at
> java.lang.reflect.Method.invokeNative(Native Method)
> E/AndroidRuntime(  315):        at
> java.lang.reflect.Method.invoke(Method.java:521)
> E/AndroidRuntime(  315):        at com.android.internal.os.ZygoteInit
> $MethodAndArgsCaller.run(ZygoteInit.java:868)
> E/AndroidRuntime(  315):        at
> com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)
> E/AndroidRuntime(  315):        at dalvik.system.NativeStart.main(Native
> Method)
>
> On 6 янв, 01:16, Paul Phillips wrote:
>
>
>
>
>
>
>
> > On Thu, Jan 5, 2012 at 1:10 PM, Alexey Aksenov wrote:
> > > How "should I fix it regardless?" :-) My ability to knowledge
> > > everything is a bit limited. I don't know internal mechanic of scala
> > > compiler. But I may regardless if needed with help of someone.
>
> > I already fixed it, but for reference, the files most likely to be relevant
> > to bytecode generation issues are:
>
> >http://github.com/scala/scala/tree/master/src/compiler/scala/tools/ns......
>
> > The change in this case:
>
> > diff --git a/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
> > b/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
> > index 241163885d..c5624a86aa 100644
> > --- a/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
> > +++ b/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
> > @@ -1199,7 +1199,7 @@ abstract class GenJVM extends SubComponent with
> > GenJVMUtil with GenAndroid with
> >        hostSymbol.info ; methodOwner.info
>
> >        def isInterfaceCall(sym: Symbol) = (
> > -           sym.isInterface
> > +           sym.isInterface && methodOwner != ObjectClass
> >          || sym.isJavaDefined &&
> > sym.isNonBottomSubClass(ClassfileAnnotationClass)
> >        )
> >        // whether to reference the type of the receiver or

under my linux system in repl output of
scala> classOf[scala.actors.IScheduler].getMethods().foreach(m
=>println(m.toString))
public abstract void scala.actors.IScheduler.shutdown()
public abstract void scala.actors.IScheduler.execute(scala.Function0)
public abstract void
scala.actors.IScheduler.execute(java.lang.Runnable)
public abstract boolean scala.actors.IScheduler.isActive()
public abstract void
scala.actors.IScheduler.terminated(scala.actors.Reactor)
public abstract void
scala.actors.IScheduler.executeFromActor(java.lang.Runnable)
public abstract void
scala.actors.IScheduler.newActor(scala.actors.Reactor)
public abstract void
scala.actors.IScheduler.onTerminate(scala.actors.Reactor,scala.Function0)
public abstract void
scala.actors.IScheduler.managedBlock(scala.concurrent.ManagedBlocker)

scala>

same. There isn't getClass method, but it is interface

Error generated by ?silly? string. Why it call getClass on interface?
looks bad

Debug.info(this+": starting new "+sched+" ["+sched.getClass+"]")

On 6 янв, 02:11, Alexey Aksenov wrote:
> Try to use reflection a bit with
>
> classOf[scala.actors.IScheduler].getMethods().foreach(m =>
> log.error(m.toString))
>
> E/o.d.d.i.s*.SSHDActivity(  338): public abstract void
> scala.actors.IScheduler.execute(java.lang.Runnable)
> E/o.d.d.i.s*.SSHDActivity(  338): public abstract void
> scala.actors.IScheduler.execute(scala.Function0)
> E/o.d.d.i.s*.SSHDActivity(  338): public abstract void
> scala.actors.IScheduler.executeFromActor(java.lang.Runnable)
> E/o.d.d.i.s*.SSHDActivity(  338): public abstract boolean
> scala.actors.IScheduler.isActive()
> E/o.d.d.i.s*.SSHDActivity(  338): public abstract void
> scala.actors.IScheduler.managedBlock(scala.concurrent.ManagedBlocker)
> E/o.d.d.i.s*.SSHDActivity(  338): public abstract void
> scala.actors.IScheduler.newActor(scala.actors.Reactor)
> E/o.d.d.i.s*.SSHDActivity(  338): public abstract void
> scala.actors.IScheduler.onTerminate(scala.actors.Reactor,scala.Function0)
> E/o.d.d.i.s*.SSHDActivity(  338): public abstract void
> scala.actors.IScheduler.shutdown()
> E/o.d.d.i.s*.SSHDActivity(  338): public abstract void
> scala.actors.IScheduler.terminated(scala.actors.Reactor)
>
> On 6 янв, 02:04, Alexey Aksenov wrote:
>
>
>
>
>
>
>
> > Unsuccessful. There was 2 attempt (I want to check that results are
> > the same)
>
> > Only difference is
> > unable to resolve interface method 1522 before
> > vs
> > unable to resolve interface method 1527 after
>
> > other numbers are same
>
> > I suspect that interface methods quantity changed: -5
>
> > Anything else?
>
> > PS Compiler code is too heavy for me. I think that I must spent a lot
> > of time (more than I have, I am afraid) to rich acceptable level of
> > knowledge for solve such type problems alone :-(
>
> > D/o.d.d.i.s*.SSHDActivity(  315): onResume(...)
> > I/dalvikvm(  315): Could not find method
> > scala.actors.IScheduler.getClass, referenced from method
> > scala.actors.scheduler.DaemonScheduler$.makeNewScheduler
> > W/dalvikvm(  315): VFY: unable to resolve interface method 1522:
> > Lscala/actors/IScheduler;.getClass ()Ljava/lang/Class;
> > D/dalvikvm(  315): VFY: replacing opcode 0x72 at 0x0032
> > D/dalvikvm(  315): VFY: dead code 0x0035-0047 in Lscala/actors/
> > scheduler/DaemonScheduler$;.makeNewScheduler ()Lscala/actors/
> > IScheduler;
> > I/dalvikvm(  315): Could not find method
> > scala.actors.IScheduler.getClass, referenced from method
> > scala.actors.Reactor$$anon$2.makeNewScheduler
> > W/dalvikvm(  315): VFY: unable to resolve interface method 1522:
> > Lscala/actors/IScheduler;.getClass ()Ljava/lang/Class;
> > D/dalvikvm(  315): VFY: replacing opcode 0x72 at 0x003f
> > D/dalvikvm(  315): VFY: dead code 0x0042-0054 in Lscala/actors/Reactor$
> > $anon$2;.makeNewScheduler ()Lscala/actors/IScheduler;
> > I/dalvikvm(  315): Could not find method scala.actors.Actor.wait,
> > referenced from method scala.actors.Actor$class.liftedTree1$1
> > W/dalvikvm(  315): VFY: unable to resolve interface method 1021:
> > Lscala/actors/Actor;.wait ()V
> > D/dalvikvm(  315): VFY: replacing opcode 0x72 at 0x0000
> > I/dalvikvm(  315): Could not find method scala.actors.Actor.notify,
> > referenced from method scala.actors.Actor$class.scala$actors$Actor$
> > $resumeActor
> > W/dalvikvm(  315): VFY: unable to resolve interface method 982: Lscala/
> > actors/Actor;.notify ()V
> > D/dalvikvm(  315): VFY: replacing opcode 0x72 at 0x0004
> > D/dalvikvm(  315): VFY: dead code 0x0007-0007 in Lscala/actors/Actor
> > $class;.scala$actors$Actor$$resumeActor (Lscala/actors/Actor;)V
> > D/AndroidRuntime(  315): Shutting down VM
> > W/dalvikvm(  315): threadid=1: thread exiting with uncaught exception
> > (group=0x4001d800)
> > E/AndroidRuntime(  315): FATAL EXCEPTION: main
> > E/AndroidRuntime(  315): java.lang.NoSuchMethodError:
> > scala.actors.IScheduler.getClass
> > E/AndroidRuntime(  315):        at scala.actors.scheduler.DaemonScheduler
> > $.makeNewScheduler(DaemonScheduler.scala:29)
> > E/AndroidRuntime(  315):        at scala.actors.scheduler.DelegatingScheduler
> > $class.newActor(DelegatingScheduler.scala:63)
> > E/AndroidRuntime(  315):        at scala.actors.scheduler.DaemonScheduler
> > $.newActor(DaemonScheduler.scala:17)
> > E/AndroidRuntime(  315):        at scala.actors.Reactor
> > $class.dostart(Reactor.scala:220)
> > E/AndroidRuntime(  315):        at scala.actors.FutureActor.scala$actors
> > $Actor$$super$dostart(Future.scala:47)
> > E/AndroidRuntime(  315):        at scala.actors.Actor
> > $class.dostart(Actor.scala:666)
> > E/AndroidRuntime(  315):        at
> > scala.actors.FutureActor.dostart(Future.scala:47)
> > E/AndroidRuntime(  315):        at scala.actors.Reactor
> > $class.start(Reactor.scala:229)
> > E/AndroidRuntime(  315):        at scala.actors.FutureActor.scala$actors
> > $Actor$$super$start(Future.scala:47)
> > E/AndroidRuntime(  315):        at scala.actors.Actor
> > $class.start(Actor.scala:670)
> > E/AndroidRuntime(  315):        at
> > scala.actors.FutureActor.start(Future.scala:47)
> > E/AndroidRuntime(  315):        at scala.actors.Futures$.future(Future.scala:
> > 122)
> > E/AndroidRuntime(  315):        at
> > org.digimead.digi.inetd.sshd.SSHDActivity.onResume(SSHDActivity.scala:
> > 94)
> > E/AndroidRuntime(  315):        at
> > android.app.Instrumentation.callActivityOnResume(Instrumentation.java:
> > 1149)
> > E/AndroidRuntime(  315):        at
> > android.app.Activity.performResume(Activity.java:3823)
> > E/AndroidRuntime(  315):        at
> > android.app.ActivityThread.performResumeActivity(ActivityThread.java:
> > 3118)
> > E/AndroidRuntime(  315):        at
> > android.app.ActivityThread.handleResumeActivity(ActivityThread.java:
> > 3143)
> > E/AndroidRuntime(  315):        at
> > android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:
> > 2684)
> > E/AndroidRuntime(  315):        at android.app.ActivityThread.access
> > $2300(ActivityThread.java:125)
> > E/AndroidRuntime(  315):        at android.app.ActivityThread
> > $H.handleMessage(ActivityThread.java:2033)
> > E/AndroidRuntime(  315):        at
> > android.os.Handler.dispatchMessage(Handler.java:99)
> > E/AndroidRuntime(  315):        at android.os.Looper.loop(Looper.java:123)
> > E/AndroidRuntime(  315):        at
> > android.app.ActivityThread.main(ActivityThread.java:4627)
> > E/AndroidRuntime(  315):        at
> > java.lang.reflect.Method.invokeNative(Native Method)
> > E/AndroidRuntime(  315):        at
> > java.lang.reflect.Method.invoke(Method.java:521)
> > E/AndroidRuntime(  315):        at com.android.internal.os.ZygoteInit
> > $MethodAndArgsCaller.run(ZygoteInit.java:868)
> > E/AndroidRuntime(  315):        at
> > com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)
> > E/AndroidRuntime(  315):        at dalvik.system.NativeStart.main(Native
> > Method)
>
> > On 6 янв, 01:16, Paul Phillips wrote:
>
> > > On Thu, Jan 5, 2012 at 1:10 PM, Alexey Aksenov wrote:
> > > > How "should I fix it regardless?" :-) My ability to knowledge
> > > > everything is a bit limited. I don't know internal mechanic of scala
> > > > compiler. But I may regardless if needed with help of someone.
>
> > > I already fixed it, but for reference, the files most likely to be relevant
> > > to bytecode generation issues are:
>
> > >http://github.com/scala/scala/tree/master/src/compiler/scala/tools/ns......
>
> > > The change in this case:
>
> > > diff --git a/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
> > > b/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
> > > index 241163885d..c5624a86aa 100644
> > > --- a/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
> > > +++ b/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
> > > @@ -1199,7 +1199,7 @@ abstract class GenJVM extends SubComponent with
> > > GenJVMUtil with GenAndroid with
> > >        hostSymbol.info ; methodOwner.info
>
> > >        def isInterfaceCall(sym: Symbol) = (
> > > -           sym.isInterface
> > > +           sym.isInterface && methodOwner != ObjectClass
> > >          || sym.isJavaDefined &&
> > > sym.isNonBottomSubClass(ClassfileAnnotationClass)
> > >        )
> > >        // whether to reference the type of the receiver or

On Thu, Jan 5, 2012 at 2:28 PM, Alexey Aksenov <alexey [dot] ezh [at] gmail [dot] com> wrote:> > Unsuccessful. There was 2 attempt (I want to check that results are > > the same)
I can see it not generating those invokeinterface calls, so my guess isyou are not testing what you think you are. For one thing you will haveto build the compiler, and then rebuild the distribution in its entirety with the new compiler, if you want to be working with the relevantbytecode.
> Why it call getClass on interface? looks bad
What was it that you thought I just fixed?

Thank you, for attempt to fix it Paul.

If I remove Debug.info strings - my application work like with scala
2.8.2

But I got old error as expected. I am sure that the only way is run
scala-test suit under android. (at least)
PS google team may be not interested at this at all (for example
because of high priority tasks)
I may help you or maybe someone else to automate testing android. All
my checks I did at standard SDK emulator under gentoo linux x64.
There is no any problems to write few scripts that allow automate
process.
IMHO The problem is to find someone that would clear bugs from scala
code. If there someone from scala development team I will help him
with great pleasure.

That's why it look like
> PS “As of December 2011 there are over 700,000 Android devices activated
> every day.” It is very disappoint that scala developers ignore such part of
> market and build compiler in unportable way, that allow to use cross
> platform language only at limited number of targets.

D/dalvikvm( 243): GC_FOR_MALLOC freed 5222 objects / 401392 bytes in
39ms
D/o.d.d.i.s*.s*.FilterAc*( 243): onCreate(...)
E/dalvikvm( 243): LinearAlloc exceeded capacity (5242880), last=104
E/dalvikvm( 243): VM aborting
I/DEBUG ( 31): *** *** *** *** *** *** *** *** *** *** *** *** ***
*** *** ***
I/DEBUG ( 31): Build fingerprint: 'generic/sdk/generic/:2.2/
FRF91/43546:eng/test-keys'

On 6 янв, 02:28, Alexey Aksenov wrote:
> under my linux system in repl output of
> scala> classOf[scala.actors.IScheduler].getMethods().foreach(m
> =>println(m.toString))
> public abstract void scala.actors.IScheduler.shutdown()
> public abstract void scala.actors.IScheduler.execute(scala.Function0)
> public abstract void
> scala.actors.IScheduler.execute(java.lang.Runnable)
> public abstract boolean scala.actors.IScheduler.isActive()
> public abstract void
> scala.actors.IScheduler.terminated(scala.actors.Reactor)
> public abstract void
> scala.actors.IScheduler.executeFromActor(java.lang.Runnable)
> public abstract void
> scala.actors.IScheduler.newActor(scala.actors.Reactor)
> public abstract void
> scala.actors.IScheduler.onTerminate(scala.actors.Reactor,scala.Function0)
> public abstract void
> scala.actors.IScheduler.managedBlock(scala.concurrent.ManagedBlocker)
>
> scala>
>
> same. There isn't getClass method, but it is interface
>
> Error generated by ?silly? string. Why it call getClass on interface?
> looks bad
>
>     Debug.info(this+": starting new "+sched+" ["+sched.getClass+"]")
>
> On 6 янв, 02:11, Alexey Aksenov wrote:
>
>
>
>
>
>
>
> > Try to use reflection a bit with
>
> > classOf[scala.actors.IScheduler].getMethods().foreach(m =>
> > log.error(m.toString))
>
> > E/o.d.d.i.s*.SSHDActivity(  338): public abstract void
> > scala.actors.IScheduler.execute(java.lang.Runnable)
> > E/o.d.d.i.s*.SSHDActivity(  338): public abstract void
> > scala.actors.IScheduler.execute(scala.Function0)
> > E/o.d.d.i.s*.SSHDActivity(  338): public abstract void
> > scala.actors.IScheduler.executeFromActor(java.lang.Runnable)
> > E/o.d.d.i.s*.SSHDActivity(  338): public abstract boolean
> > scala.actors.IScheduler.isActive()
> > E/o.d.d.i.s*.SSHDActivity(  338): public abstract void
> > scala.actors.IScheduler.managedBlock(scala.concurrent.ManagedBlocker)
> > E/o.d.d.i.s*.SSHDActivity(  338): public abstract void
> > scala.actors.IScheduler.newActor(scala.actors.Reactor)
> > E/o.d.d.i.s*.SSHDActivity(  338): public abstract void
> > scala.actors.IScheduler.onTerminate(scala.actors.Reactor,scala.Function0)
> > E/o.d.d.i.s*.SSHDActivity(  338): public abstract void
> > scala.actors.IScheduler.shutdown()
> > E/o.d.d.i.s*.SSHDActivity(  338): public abstract void
> > scala.actors.IScheduler.terminated(scala.actors.Reactor)
>
> > On 6 янв, 02:04, Alexey Aksenov wrote:
>
> > > Unsuccessful. There was 2 attempt (I want to check that results are
> > > the same)
>
> > > Only difference is
> > > unable to resolve interface method 1522 before
> > > vs
> > > unable to resolve interface method 1527 after
>
> > > other numbers are same
>
> > > I suspect that interface methods quantity changed: -5
>
> > > Anything else?
>
> > > PS Compiler code is too heavy for me. I think that I must spent a lot
> > > of time (more than I have, I am afraid) to rich acceptable level of
> > > knowledge for solve such type problems alone :-(
>
> > > D/o.d.d.i.s*.SSHDActivity(  315): onResume(...)
> > > I/dalvikvm(  315): Could not find method
> > > scala.actors.IScheduler.getClass, referenced from method
> > > scala.actors.scheduler.DaemonScheduler$.makeNewScheduler
> > > W/dalvikvm(  315): VFY: unable to resolve interface method 1522:
> > > Lscala/actors/IScheduler;.getClass ()Ljava/lang/Class;
> > > D/dalvikvm(  315): VFY: replacing opcode 0x72 at 0x0032
> > > D/dalvikvm(  315): VFY: dead code 0x0035-0047 in Lscala/actors/
> > > scheduler/DaemonScheduler$;.makeNewScheduler ()Lscala/actors/
> > > IScheduler;
> > > I/dalvikvm(  315): Could not find method
> > > scala.actors.IScheduler.getClass, referenced from method
> > > scala.actors.Reactor$$anon$2.makeNewScheduler
> > > W/dalvikvm(  315): VFY: unable to resolve interface method 1522:
> > > Lscala/actors/IScheduler;.getClass ()Ljava/lang/Class;
> > > D/dalvikvm(  315): VFY: replacing opcode 0x72 at 0x003f
> > > D/dalvikvm(  315): VFY: dead code 0x0042-0054 in Lscala/actors/Reactor$
> > > $anon$2;.makeNewScheduler ()Lscala/actors/IScheduler;
> > > I/dalvikvm(  315): Could not find method scala.actors.Actor.wait,
> > > referenced from method scala.actors.Actor$class.liftedTree1$1
> > > W/dalvikvm(  315): VFY: unable to resolve interface method 1021:
> > > Lscala/actors/Actor;.wait ()V
> > > D/dalvikvm(  315): VFY: replacing opcode 0x72 at 0x0000
> > > I/dalvikvm(  315): Could not find method scala.actors.Actor.notify,
> > > referenced from method scala.actors.Actor$class.scala$actors$Actor$
> > > $resumeActor
> > > W/dalvikvm(  315): VFY: unable to resolve interface method 982: Lscala/
> > > actors/Actor;.notify ()V
> > > D/dalvikvm(  315): VFY: replacing opcode 0x72 at 0x0004
> > > D/dalvikvm(  315): VFY: dead code 0x0007-0007 in Lscala/actors/Actor
> > > $class;.scala$actors$Actor$$resumeActor (Lscala/actors/Actor;)V
> > > D/AndroidRuntime(  315): Shutting down VM
> > > W/dalvikvm(  315): threadid=1: thread exiting with uncaught exception
> > > (group=0x4001d800)
> > > E/AndroidRuntime(  315): FATAL EXCEPTION: main
> > > E/AndroidRuntime(  315): java.lang.NoSuchMethodError:
> > > scala.actors.IScheduler.getClass
> > > E/AndroidRuntime(  315):        at scala.actors.scheduler.DaemonScheduler
> > > $.makeNewScheduler(DaemonScheduler.scala:29)
> > > E/AndroidRuntime(  315):        at scala.actors.scheduler.DelegatingScheduler
> > > $class.newActor(DelegatingScheduler.scala:63)
> > > E/AndroidRuntime(  315):        at scala.actors.scheduler.DaemonScheduler
> > > $.newActor(DaemonScheduler.scala:17)
> > > E/AndroidRuntime(  315):        at scala.actors.Reactor
> > > $class.dostart(Reactor.scala:220)
> > > E/AndroidRuntime(  315):        at scala.actors.FutureActor.scala$actors
> > > $Actor$$super$dostart(Future.scala:47)
> > > E/AndroidRuntime(  315):        at scala.actors.Actor
> > > $class.dostart(Actor.scala:666)
> > > E/AndroidRuntime(  315):        at
> > > scala.actors.FutureActor.dostart(Future.scala:47)
> > > E/AndroidRuntime(  315):        at scala.actors.Reactor
> > > $class.start(Reactor.scala:229)
> > > E/AndroidRuntime(  315):        at scala.actors.FutureActor.scala$actors
> > > $Actor$$super$start(Future.scala:47)
> > > E/AndroidRuntime(  315):        at scala.actors.Actor
> > > $class.start(Actor.scala:670)
> > > E/AndroidRuntime(  315):        at
> > > scala.actors.FutureActor.start(Future.scala:47)
> > > E/AndroidRuntime(  315):        at scala.actors.Futures$.future(Future.scala:
> > > 122)
> > > E/AndroidRuntime(  315):        at
> > > org.digimead.digi.inetd.sshd.SSHDActivity.onResume(SSHDActivity.scala:
> > > 94)
> > > E/AndroidRuntime(  315):        at
> > > android.app.Instrumentation.callActivityOnResume(Instrumentation.java:
> > > 1149)
> > > E/AndroidRuntime(  315):        at
> > > android.app.Activity.performResume(Activity.java:3823)
> > > E/AndroidRuntime(  315):        at
> > > android.app.ActivityThread.performResumeActivity(ActivityThread.java:
> > > 3118)
> > > E/AndroidRuntime(  315):        at
> > > android.app.ActivityThread.handleResumeActivity(ActivityThread.java:
> > > 3143)
> > > E/AndroidRuntime(  315):        at
> > > android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:
> > > 2684)
> > > E/AndroidRuntime(  315):        at android.app.ActivityThread.access
> > > $2300(ActivityThread.java:125)
> > > E/AndroidRuntime(  315):        at android.app.ActivityThread
> > > $H.handleMessage(ActivityThread.java:2033)
> > > E/AndroidRuntime(  315):        at
> > > android.os.Handler.dispatchMessage(Handler.java:99)
> > > E/AndroidRuntime(  315):        at android.os.Looper.loop(Looper.java:123)
> > > E/AndroidRuntime(  315):        at
> > > android.app.ActivityThread.main(ActivityThread.java:4627)
> > > E/AndroidRuntime(  315):        at
> > > java.lang.reflect.Method.invokeNative(Native Method)
> > > E/AndroidRuntime(  315):        at
> > > java.lang.reflect.Method.invoke(Method.java:521)
> > > E/AndroidRuntime(  315):        at com.android.internal.os.ZygoteInit
> > > $MethodAndArgsCaller.run(ZygoteInit.java:868)
> > > E/AndroidRuntime(  315):        at
> > > com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)
> > > E/AndroidRuntime(  315):        at dalvik.system.NativeStart.main(Native
> > > Method)
>
> > > On 6 янв, 01:16, Paul Phillips wrote:
>
> > > > On Thu, Jan 5, 2012 at 1:10 PM, Alexey Aksenov wrote:
> > > > > How "should I fix it regardless?" :-) My ability to knowledge
> > > > > everything is a bit limited. I don't know internal mechanic of scala
> > > > > compiler. But I may regardless if needed with help of someone.
>
> > > > I already fixed it, but for reference, the files most likely to be relevant
> > > > to bytecode generation issues are:
>
> > > >http://github.com/scala/scala/tree/master/src/compiler/scala/tools/ns......
>
> > > > The change in this case:
>
> > > > diff --git a/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
> > > > b/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
> > > > index 241163885d..c5624a86aa 100644
> > > > --- a/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
> > > > +++ b/src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
> > > > @@ -1199,7 +1199,7 @@ abstract class GenJVM extends SubComponent with
> > > > GenJVMUtil with GenAndroid with
> > > >        hostSymbol.info ; methodOwner.info
>
> > > >        def isInterfaceCall(sym: Symbol) = (
> > > > -           sym.isInterface
> > > > +           sym.isInterface && methodOwner != ObjectClass
> > > >          || sym.isJavaDefined &&
> > > > sym.isNonBottomSubClass(ClassfileAnnotationClass)
> > > >        )
> > > >        // whether to reference the type of the receiver or

> I can see it not generating those invokeinterface calls, so my guess is
> you are not testing what you think you are. For one thing you will have
> to build the compiler, and then rebuild the distribution in its entirety
> with the new compiler, if you want to be working with the relevant
> bytecode.

Seems so, Paul
Let me ask, latest git copy build properly at your environment if you
replace lib/scala* with latest?
Maybe you are right, but when I replace lib/scala*.jar with files from
dist, I got

init:
[echo] build time: 6 January 2012, 03:34:36
[echo] java version: OpenJDK 64-Bit Server VM 1.6.0_22
[echo] java args: -Xms1536M -Xmx1536M -Xss1M -
XX:MaxPermSize=192M -XX:+UseParallelGC
[echo] javac args:
[echo] scalac args:
[echo] build number: 2.10.0.rdev-4118-2012-01-06-gbe46e48
[mkdir] Created dir: /home/ezh/0projectsAndroid/junk/scala/lib/
extra

locker.start:

locker.pre-lib:

locker.lib:
[mkdir] Created dir: /home/ezh/0projectsAndroid/junk/scala/build/
locker/classes/library
[javac] Compiling 25 source files to /home/ezh/0projectsAndroid/
junk/scala/build/locker/classes/library
[scalacfork] Compiling 687 files to /home/ezh/0projectsAndroid/junk/
scala/build/locker/classes/library
[scalacfork] /home/ezh/0projectsAndroid/junk/scala/src/library/scala/
collection/parallel/Tasks.scala:15: error: object forkjoin is not a
member of package concurrent
[scalacfork] import scala.concurrent.forkjoin._
[scalacfork] ^
[scalacfork] /home/ezh/0projectsAndroid/junk/scala/src/library/scala/
collection/parallel/Tasks.scala:459: error: value fork is not a member
of ForkJoinTasks.this.TaskImpl[R,Tp]
[scalacfork] fjtask.fork
[scalacfork] ^
[scalacfork] /home/ezh/0projectsAndroid/junk/scala/src/library/scala/
collection/parallel/Tasks.scala:482: error: value fork is not a member
of ForkJoinTasks.this.TaskImpl[R,Tp]
[scalacfork] fjtask.fork
[scalacfork] ^
[scalacfork] three errors found

BUILD FAILED
/home/ezh/0projectsAndroid/junk/scala/build.xml:341:
java.lang.RuntimeException: Compilation failed because of an internal
compiler error; see the error output for details.
at scala.sys.package$.error(package.scala:27)
at scala.tools.ant.sabbus.ScalacFork.execute(ScalacFork.scala:153)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:
291)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:
106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:
1397)
at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:
41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
at org.apache.tools.ant.Main.runBuild(Main.java:801)
at org.apache.tools.ant.Main.startAnt(Main.java:218)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)

Total time: 23 seconds

On 6 янв, 02:52, Paul Phillips wrote:
> On Thu, Jan 5, 2012 at 2:28 PM, Alexey Aksenov wrote:
> > > Unsuccessful. There was 2 attempt (I want to check that results are
> > > the same)
>
> I can see it not generating those invokeinterface calls, so my guess is
> you are not testing what you think you are. For one thing you will have
> to build the compiler, and then rebuild the distribution in its entirety
> with the new compiler, if you want to be working with the relevant
> bytecode.
>
> > Why it call getClass on interface? looks bad
>
> What was it that you thought I just fixed?

On Thu, Jan 5, 2012 at 3:40 PM, Alexey Aksenov <alexey [dot] ezh [at] gmail [dot] com> wrote:

Let me ask, latest git copy build properly at your environment if you
replace lib/scala* with latest?

No, that's not how to do it.
  ant all.clean build
(I'm not sure of the state of the sbt build, so ant is the safe way.)
Then use the jars in ./build/pack/lib, which will have been built by a compiler built from the contents of src/.

On Thu, Jan 5, 2012 at 3:11 PM, Alexey Aksenov <alexey [dot] ezh [at] gmail [dot] com> wrote:

IMHO The problem is to find someone that would clear bugs from scala
code. If there someone from scala development team I will help him
with great pleasure.

You can't say the raised issues haven't been fixed pretty speedily thus far.  (I'm assuming you will eventually find I did indeed fix the invokeinterface issue.) If you want to create an automated test rig for scala on android, I think it's a lovely idea - I'll help as much as I can, which isn't much.  If you can find someone else, all the better, but someone elses are hard to come by. I think I'm pretty good at prioritizing issues raised by people who are moving the ball a little ways on their own, so give it a shot.  What's the worst that can happen.