Status Update
Comments
jo...@gmail.com <jo...@gmail.com> #2
On my phone runs Android 2.3 so that's what I tested it with. However, there is no obvious reason this would be fixed in ICS even if LinearAlloc size seems to be now increased to 8Mb.
en...@google.com <en...@google.com>
ja...@gmail.com <ja...@gmail.com> #3
Testing here too, prevents pre-installing dex scala libraries.
Having to wait 2 minutes to deploy every time is almost as undesirable as having to use Java instead of Scala ;)
Having to wait 2 minutes to deploy every time is almost as undesirable as having to use Java instead of Scala ;)
ja...@gmail.com <ja...@gmail.com> #4
Sorry shoulda pointed out: using Android 4.0.3 here in the emulator and seeing the same issue.
je...@google.com <je...@google.com> #5
Can't you fix this in the Scala compiler?
je...@google.com <je...@google.com>
ja...@gmail.com <ja...@gmail.com> #6
Maybe you could "fix" it in the Scala compiler, but compilers are complex by nature and these kinds of inheritance chains don't necessarily construe "brokenness".
In my opinion I confer the responsibility to android, for failing to deal with an inherently complex library that many people want to use.
In my opinion I confer the responsibility to android, for failing to deal with an inherently complex library that many people want to use.
ja...@gmail.com <ja...@gmail.com> #7
I don't think it's unreasonable to assume that people will want to use progressively more complex libraries as more developers come to android and creating increasingly complex phone applications.
I'd think if this bug isn't fixed for scala you'll start getting more and more people hitting the same thing.
I'd think if this bug isn't fixed for scala you'll start getting more and more people hitting the same thing.
al...@gmail.com <al...@gmail.com> #8
I suppose that is a bit confusing too. Is it any reasons to keep so small amount of memory? For example, create software for tablet with 1GB of memory. And have been limited with 8Mb of DEFAULT_MAX_LENGTH. It is is a bit disappointing. FYI fully loaded scala 2.9 with all interfaces required 10Mb (maybe there is a bad design, but we have 1GB!!!).
Most of new smart phones have more than 256Mb. Is it possible to change this limit at boot time? Also LinearAlloc grow dynamically...
Optimizing scala compiler, profiling scala library, profiling java libraries, try to reach 3rd party developers - terrible. VS covert constant to variable and set it with reasonable value at boot time. Or is there any other reasons?
Most of new smart phones have more than 256Mb. Is it possible to change this limit at boot time? Also LinearAlloc grow dynamically...
Optimizing scala compiler, profiling scala library, profiling java libraries, try to reach 3rd party developers - terrible. VS covert constant to variable and set it with reasonable value at boot time. Or is there any other reasons?
jo...@gmail.com <jo...@gmail.com> #9
@jesse: Attempts were already made to improve the Scala compiler and this may bring fruit sooner or later.
However, regardless of Scala, since the space needed for the interfaces grows more than linear with the depth of the interface hierarchy we can get easily into the problematic territory again if only one level of interface inheritance will be inserted for some reason.
Don't you think the fix is simple enough to be included?
However, regardless of Scala, since the space needed for the interfaces grows more than linear with the depth of the interface hierarchy we can get easily into the problematic territory again if only one level of interface inheritance will be inserted for some reason.
Don't you think the fix is simple enough to be included?
je...@google.com <je...@google.com> #10
I haven't reviewed the fix. Unfortunately our official system for accepting third party patches is temporarily unavailable; when it comes back online you should submit the patch using the process here:
http://source.android.com/source/submit-patches.html
That process guarantees you've done the contributor agreement, and it'll give you credit in git history. It also allows us to go back and forth on the patch.
The more immediate alternative is us fixing it without looking at your patch. I've asked Jeff to look at this. Since you've provided a rather awesome test case it shouldn't be much work!
That process guarantees you've done the contributor agreement, and it'll give you credit in git history. It also allows us to go back and forth on the patch.
The more immediate alternative is us fixing it without looking at your patch. I've asked Jeff to look at this. Since you've provided a rather awesome test case it shouldn't be much work!
un...@gmail.com <un...@gmail.com> #11
Hi Jesse,
Thank you for your response! That's one of the best responses I've ever seen from a 'corporate' open source project.
Thank you for your response! That's one of the best responses I've ever seen from a 'corporate' open source project.
je...@google.com <je...@google.com> #12
jo...@gmail.com <jo...@gmail.com> #13
Jesse, I don't see anything Android specific on the review page? Where and how should I add the patch?
I once submitted a patch to the old android review system when it was still running. I can't remember but I think I must have signed the contributor's agreement then.
I guess the usual Android patch submitting workflow doesn't apply for the gerrit-review page you gave?
I once submitted a patch to the old android review system when it was still running. I can't remember but I think I must have signed the contributor's agreement then.
I guess the usual Android patch submitting workflow doesn't apply for the gerrit-review page you gave?
je...@google.com <je...@google.com> #14
johannes.rudolph, the new codereview site is apparently still working out some kinks! Does this one work for you? https://android-review.googlesource.com/
In any case the instructions on the theandroid.com site will be updated soon.
In any case the instructions on the the
en...@google.com <en...@google.com>
cf...@gmail.com <cf...@gmail.com> #16
Thanks for fixing this!
ra...@gmail.com <ra...@gmail.com> #17
Anuwar Anuwar100063946082654
Description
public class Test {
interface A1 {}
interface A2 {}
interface A3 {}
interface A4 {}
interface A5 {}
// [...] B - G analogous
interface H1 extends G1, G2, G3, G4, G5 {}
interface H2 extends G1, G2, G3, G4, G5 {}
interface H3 extends G1, G2, G3, G4, G5 {}
interface H4 extends G1, G2, G3, G4, G5 {}
interface H5 extends G1, G2, G3, G4, G5 {}
interface Z extends H1, H2, H3, H4, H5 {}
}
fails to dexopt with
E/dalvikvm( 7815): LinearAlloc exceeded capacity (5242880), last=3906240
The example seems like a contrived way to structure your interfaces but it is not so unlikely if you use a library sophisticated enough. In our concrete case the Scala collection library is the problem. See [2] for more info.
I compiled dalvik with more debugging output and this is what we got:
[...]
D/dalvikvm( 7815): --- LinearAlloc(interfaces, 0x0, 20)
I/dalvikvm( 7815): --- old=3330796 size=20 new=3330820 now at=3326720
D/dalvikvm( 7815): CLASS: linking 'LTest$H4;'...
D/dalvikvm( 7815): --- LinearAlloc(iftable, 0x0, 781240)
I/dalvikvm( 7815): --- old=3330820 size=781240 new=4112068 now at=4107968
D/dalvikvm( 7815): --- LinearAlloc(interfaces, 0x0, 20)
I/dalvikvm( 7815): --- old=4112068 size=20 new=4112092 now at=4107992
D/dalvikvm( 7815): CLASS: linking 'LTest$H5;'...
D/dalvikvm( 7815): --- LinearAlloc(iftable, 0x0, 781240)
I/dalvikvm( 7815): --- old=4112092 size=781240 new=4893340 now at=4889240
D/dalvikvm( 7815): --- LinearAlloc(interfaces, 0x0, 20)
I/dalvikvm( 7815): --- old=4893340 size=20 new=4893364 now at=4889264
D/dalvikvm( 7815): CLASS: linking 'LTest$Z;'...
D/dalvikvm( 7815): --- LinearAlloc(iftable, 0x0, 3906240)
I/dalvikvm( 7815): --- old=4893364 size=3906240 new=8799612 now at=8795512
E/dalvikvm( 7815): LinearAlloc exceeded capacity (5242880), last=3906240
The problem is the way in which the dalvik vm is collecting interfaces. It doesn't check for redundant interfaces introduced by multiple interface inheritance.
There is some `if (false)`-ed code which did that originally, but it was inactivated with this comment (vm/oo/Class.cpp):
UPDATE: this makes ReferenceType.Interfaces difficult to implement,
because it wants to return just the interfaces declared to be
implemented directly by the class. I'm excluding this code for now.
I don't think this claim is valid because as witnessed by this bug report [3], `ReferenceType.Interfaces` (from the JDWP interface) never worked properly anyways.
This out of the way (and I looked also at the other positions this might be a problem), here's a patch which solves the issue by removing duplicate interface definitions.
[1]
[2]
[3]