7 ms·

There's no reason for a stack that is (linux kernel + android hal + web runtime) to require more resources than (linux kernel + android hal + dalvik and a java

There's no reason for a stack that is (linux kernel + android hal + web runtime) to require more resources than (linux kernel + android hal + dalvik and a java toolkit). Android is barely usable on these devices. Firefox OS run really well. But of course I'm biaised, I spent a bit too much time on this project ;)

zanny 12y ago
I think the point is more kernel + libc + binaries is the maximally leanest. Putting any interpreter on top of that is always a huge overhead, be it Dalvik or Gecko / Spidermonkey. And worst of all (or best?) is that it seems we are moving towards this thing where Mono and Qt are also on phones, meaning you have two parallel stacks - one interpreter and one big ass shared library or another interpreter - running at once.
- azakai 12y ago
  It is more complicated than that, though. Yes, while you can build a kernel+libc+binary code application that is pretty lean, that means that your kernel plus graphics stack need to handle both that type of application, as well as a web browser and related content. In some cases, having to handle just one of those opens up optimization opportunities, either in the kernel, libc, or the graphics stack. If you can run only native binaries using a single graphics method, that might be overall leanest, but every phone needs a browser these days. So the only other option to have a single thing to optimize for is to make the only stack the web stack. Then, whatever is optimal for the browser in terms of handling GPU textures, as one example, you can just do, because nothing else needs to run as well.
- ibisum 12y ago
  kernel + libc + luajit == *ahem*
jlebar 12y ago
> There's no reason for a stack that is (linux kernel + > android hal + web runtime) to require more resources than > (linux kernel + android hal + dalvik and a java toolkit). Correct, but likewise there's no good reason for (linux + android hal + web) to require /less/ ram than (linux + android hal + dalvik and java toolkit). Even if we accept the claim that most of the time on Android you have both dalvik and webkit loaded at once, whereas on B2G you only have gecko running, claiming that this necessarily means that B2G uses less memory is akin to claiming that x + y > z for arbitrary values of x, y, and z, which is obviously silly. But I don't need to tell you that this claim that B2G uses less memory by design was a major frustration to me back when I owned B2G memory usage. :) If FFOS is small, it's because you and I and others worked really hard to make it so.
- illumen 12y ago
  Java Is anyone really surprised that Java is not so good for interactive applications? It's never been in first place for that type of app.
  - icebraining 12y ago
    That's not true, the first version of Java came with Java Applets, which are interactive applications.
    - vidarh 12y ago
      Does anyone actually have good memories of the responsiveness of Applets? If anything, Applets is still to an extent responsible for a lot of the negative opinions of Java's performance and suitability for interactive applications.
      - illumen 12y ago
        The GC, and the JIT are the two main problems with Java for this use case. Both require pauses in execution, which for real time apps is a mode of failure. Also, doing things in separate threads means that scheduling of tasks also causes pauses in execution.
        moonchrome 12y ago
        >The GC, and the JIT are the two main problems with Java for this use case. Both require pauses in execution, which for real time apps is a mode of failure. Umm, JavaScript and DOM/HTML have the exact same problem except it's magnified by the fact that the language is much more complex to JIT compile (statically typed bytecode vs dynamic/weak typed source code) and the GC has to deal with managed/native interop in the DOM. And not to mention the cost of inefficient DOM interfaces and silly data structures/native types in JS. >Also, doing things in separate threads means that scheduling of tasks also causes pauses in execution. Yea, on the order of milliseconds at worst. Unless we're talking about real time software like games which need to execute a simulation iteration 30-60 times per second (and JS is much worse for this than Java for the reasons mentioned) delays in a reasonably well implemented UI app shouldn't matter and JIT startup time can be avoided by AOT (which is much simpler for static typed languages)
kenrikm 12y ago
I think it's more a matter of the amount of RAM the apps use, 128megs does not leave room for much. Though in any case it seems like you would be very limited in what you're able to do with the apps.
- frik 12y ago
  128MB ram is a lot. I had a notebook with 128MB ram running Windows 2000 and Photoshop. It's just that Java (and to lesser extend Object C) is such a resource hog. The future are apps written in C/C++, Go, Rust, Julia, Swift or JS (FirefoxOS). As someone pointed out above, JavaScript is more memory efficient (first order function, etc.).
  - fabrice_d 12y ago
    128MB on a phone is not that much, because the modem RTOS will use some, and the GPU too. Add to that the main kernel needs some, and there's not a lot left for user space...
    - kenrikm 12y ago
      Indeed I remember programming for the iPhone 3G was pretty painful back in the day, you had to get creative about loading resources and make sure they were released right away even if you might be using them again.
zmmmmm 12y ago
But there IS a reason. Java is a far more statically typed language than Javascript. That enables certain optimizations that will simply never be viable in Javascript, at least as it it is generally used. You can make an argument that this isn't the case for FFOS for some special reasons, but I don't think you can legitimately make a claim that there's "no reason" and leave it at that.
- tomp 12y ago
  Actually, no. Java is a far more primitive language than JS, and it's specification require it to consume large amounts of memory. In Java, all objects need to have at least one additional field so that they can be used for synchronization. Most JS engines, on the other hand, support tagging (floats/doubles/ints are stored unboxed). In Java, everything needs to be statically typed, and every object needs a class. If you want to make a first-class function, you need a classfile, a class, and an actual full-blown object for that function. In JavaScript (and other languages supporting first-class functions), closures can be optimized and represented by a single "closure" class, which has an existential type (the tuple of types of closed-over variables) and which is guaranteed to be correct (sound) by construction. Modern JIT engines work very very well for the majority of "nice" (strict) dynamically-typed code. Where you lose is (1) numerics (where Java sucks as well, no vectorization - JavaScript is probably better here, with WebGL) and (2) non-polymorphic function calls (which are quite rare in Java as well). For polymorphic functions, polymorphic inline caches perform very well, probably not much worse than virtual/interface calls.
  - oldmanjay 12y ago
    >If you want to make a first-class function, you need a classfile, a class, and an actual full-blown object for that function. this isn't wholly true as of java 8. dynamic invocation is used to implement the new lambda facility.
    - oldmanjay 12y ago
      replying to myself to add info, in case anyone stumbles across this. I was only half correct - the current implementation does generate a dynamic invocation in bytecode, but the bootstrap framework that binds the call site ends up generating a class at runtime to "seal the deal" as it were. I hadn't read through all the details before now. one source with many links: http://www.takipiblog.com/compiling-lambda-expressions-scala-vs-java-8/ http://www.takipiblog.com/compiling-lambda-expressions-scala...
Sanddancer 12y ago
Aye, but Android's moving to an AOT runtime with libart, which has shown some pretty significant performance and memory consumption improvements. I'm curious how much better performance you'd get from Firefox OS if there were a similar AOT option available for it.
- burgers 12y ago
  How about OdinMonkey for asm.js?[1] [1] https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/ https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilat...

zanny 12y ago

I think the point is more kernel + libc + binaries is the maximally leanest. Putting any interpreter on top of that is always a huge overhead, be it Dalvik or Gecko / Spidermonkey. And worst of all (or best?) is that it seems we are moving towards this thing where Mono and Qt are also on phones, meaning you have two parallel stacks - one interpreter and one big ass shared library or another interpreter - running at once.

azakai 12y ago
It is more complicated than that, though. Yes, while you can build a kernel+libc+binary code application that is pretty lean, that means that your kernel plus graphics stack need to handle both that type of application, as well as a web browser and related content. In some cases, having to handle just one of those opens up optimization opportunities, either in the kernel, libc, or the graphics stack. If you can run only native binaries using a single graphics method, that might be overall leanest, but every phone needs a browser these days. So the only other option to have a single thing to optimize for is to make the only stack the web stack. Then, whatever is optimal for the browser in terms of handling GPU textures, as one example, you can just do, because nothing else needs to run as well.
ibisum 12y ago
kernel + libc + luajit == *ahem*

jlebar 12y ago

> There's no reason for a stack that is (linux kernel + > android hal + web runtime) to require more resources than > (linux kernel + android hal + dalvik and a java toolkit). Correct, but likewise there's no good reason for (linux + android hal + web) to require /less/ ram than (linux + android hal + dalvik and java toolkit). Even if we accept the claim that most of the time on Android you have both dalvik and webkit loaded at once, whereas on B2G you only have gecko running, claiming that this necessarily means that B2G uses less memory is akin to claiming that x + y > z for arbitrary values of x, y, and z, which is obviously silly. But I don't need to tell you that this claim that B2G uses less memory by design was a major frustration to me back when I owned B2G memory usage. :) If FFOS is small, it's because you and I and others worked really hard to make it so.

illumen 12y ago
Java Is anyone really surprised that Java is not so good for interactive applications? It's never been in first place for that type of app.
- icebraining 12y ago
  That's not true, the first version of Java came with Java Applets, which are interactive applications.
  - vidarh 12y ago
    Does anyone actually have good memories of the responsiveness of Applets? If anything, Applets is still to an extent responsible for a lot of the negative opinions of Java's performance and suitability for interactive applications.
    - illumen 12y ago
      The GC, and the JIT are the two main problems with Java for this use case. Both require pauses in execution, which for real time apps is a mode of failure. Also, doing things in separate threads means that scheduling of tasks also causes pauses in execution.
      - moonchrome 12y ago
        >The GC, and the JIT are the two main problems with Java for this use case. Both require pauses in execution, which for real time apps is a mode of failure. Umm, JavaScript and DOM/HTML have the exact same problem except it's magnified by the fact that the language is much more complex to JIT compile (statically typed bytecode vs dynamic/weak typed source code) and the GC has to deal with managed/native interop in the DOM. And not to mention the cost of inefficient DOM interfaces and silly data structures/native types in JS. >Also, doing things in separate threads means that scheduling of tasks also causes pauses in execution. Yea, on the order of milliseconds at worst. Unless we're talking about real time software like games which need to execute a simulation iteration 30-60 times per second (and JS is much worse for this than Java for the reasons mentioned) delays in a reasonably well implemented UI app shouldn't matter and JIT startup time can be avoided by AOT (which is much simpler for static typed languages)

kenrikm 12y ago

I think it's more a matter of the amount of RAM the apps use, 128megs does not leave room for much. Though in any case it seems like you would be very limited in what you're able to do with the apps.

frik 12y ago
128MB ram is a lot. I had a notebook with 128MB ram running Windows 2000 and Photoshop. It's just that Java (and to lesser extend Object C) is such a resource hog. The future are apps written in C/C++, Go, Rust, Julia, Swift or JS (FirefoxOS). As someone pointed out above, JavaScript is more memory efficient (first order function, etc.).
- fabrice_d 12y ago
  128MB on a phone is not that much, because the modem RTOS will use some, and the GPU too. Add to that the main kernel needs some, and there's not a lot left for user space...
  - kenrikm 12y ago
    Indeed I remember programming for the iPhone 3G was pretty painful back in the day, you had to get creative about loading resources and make sure they were released right away even if you might be using them again.

zmmmmm 12y ago

But there IS a reason. Java is a far more statically typed language than Javascript. That enables certain optimizations that will simply never be viable in Javascript, at least as it it is generally used. You can make an argument that this isn't the case for FFOS for some special reasons, but I don't think you can legitimately make a claim that there's "no reason" and leave it at that.

tomp 12y ago
Actually, no. Java is a far more primitive language than JS, and it's specification require it to consume large amounts of memory. In Java, all objects need to have at least one additional field so that they can be used for synchronization. Most JS engines, on the other hand, support tagging (floats/doubles/ints are stored unboxed). In Java, everything needs to be statically typed, and every object needs a class. If you want to make a first-class function, you need a classfile, a class, and an actual full-blown object for that function. In JavaScript (and other languages supporting first-class functions), closures can be optimized and represented by a single "closure" class, which has an existential type (the tuple of types of closed-over variables) and which is guaranteed to be correct (sound) by construction. Modern JIT engines work very very well for the majority of "nice" (strict) dynamically-typed code. Where you lose is (1) numerics (where Java sucks as well, no vectorization - JavaScript is probably better here, with WebGL) and (2) non-polymorphic function calls (which are quite rare in Java as well). For polymorphic functions, polymorphic inline caches perform very well, probably not much worse than virtual/interface calls.
- oldmanjay 12y ago
  >If you want to make a first-class function, you need a classfile, a class, and an actual full-blown object for that function. this isn't wholly true as of java 8. dynamic invocation is used to implement the new lambda facility.
  - oldmanjay 12y ago
    replying to myself to add info, in case anyone stumbles across this. I was only half correct - the current implementation does generate a dynamic invocation in bytecode, but the bootstrap framework that binds the call site ends up generating a class at runtime to "seal the deal" as it were. I hadn't read through all the details before now. one source with many links: http://www.takipiblog.com/compiling-lambda-expressions-scala-vs-java-8/ http://www.takipiblog.com/compiling-lambda-expressions-scala...

Sanddancer 12y ago

Aye, but Android's moving to an AOT runtime with libart, which has shown some pretty significant performance and memory consumption improvements. I'm curious how much better performance you'd get from Firefox OS if there were a similar AOT option available for it.

burgers 12y ago
How about OdinMonkey for asm.js?[1] [1] https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/ https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilat...