More concretely, I’m asking this: why aren’t applications compiled fully to native code before distribution rather than bytecode that runs on some virtual machine or runtime environment?

Implementation details aside, fundamentally, an Android application consists of bytecode, static resources, etc. In the Java world, I understand that the main appeal of having the JVM is to allow for enhanced portability and maybe also improved security. I know Android uses ART, but it remains that the applications are composed of processor-independent bytecode that leads to all this complex design to convert it into runnable code in some efficient manner. See: ART optimizing profiles, JIT compilation, JIT/AOT Hybrid Compilation… that’s a lot of work to support this complex design.

Android only officially supports arm64 currently, so why the extra complexity? Is this a vestigial remnant of the past? If so, with the move up in minimum supported versions, I should think Android should be transitioning to a binary distribution model at a natural point where compatibility is breaking. What benefit is being realized from all this runtime complexity?

  • lightrush
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    1 year ago

    There are many benefits. For example great exception handling. We’re paying very little performance cost for having the conveniences of a managed runtime. Let me flip it, we don’t want unmanaged runtimes, we are forced to run in native, because we need the absolute highest performance in some cases. If the hardware could understand Java bytecode and provide all other JVM facilities, that would have been spectacular. Unfortunately that would be very expensive and pointless as we’ve demonstrated over the decades. If anything we’re moving towards reduced instruction set chips - ARM, RISC-V. And so in many ways the complexity you see is well understood by the folks that have to understand it, it’s well managed, it’s worth it and it’s not at all a performance problem worth tackling.

    • aluminium@lemmy.world
      link
      fedilink
      English
      arrow-up
      6
      ·
      1 year ago

      If the hardware could understand Java bytecode

      This actually existed on ARM to improve performance of java games on pre-smartphone area phones, it was called jazelle.

      • lightrush
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        1 year ago

        This name rings a bell. Was that used along with J2ME?

        • aluminium@lemmy.world
          link
          fedilink
          English
          arrow-up
          3
          ·
          1 year ago

          Probably, but I have never used it. I only found out about it when researching about AoT compiling for Java and thought - hugh, neat idea.

          • lightrush
            link
            fedilink
            English
            arrow-up
            2
            ·
            edit-2
            1 year ago

            Related - something I learned during a research course at uni - the shifting of some functionality from software to hardware or the other way around has happened on many occasions. It all depends on how the tradeoffs between performance, optimization, cost and so on shake out.