4 ms·

Going against what Linus suggests, The Dalvik DEX format (used by Android) has a flag representing the endianness of the enclosed bytecode: https://source.andro

Going against what Linus suggests, The Dalvik DEX format (used by Android) has a flag representing the endianness of the enclosed bytecode: https://source.android.com/devices/tech/dalvik/dex-format.html https://source.android.com/devices/tech/dalvik/dex-format.ht... (see "ENDIAN_CONSTANT and REVERSE_ENDIAN_CONSTANT"). By default, it's Little Endian. I've always wondered WHY this flag is present - why would an implementation wish to change the byte-order? I could understand if the file contained machine code, and would vary with different architectures - but given it's running in a VM, why bother?

davtbaum 11y ago
Even though the bytecode is being executed on a VM, the VM itself has been ported to the architecture, which has a native endianness. Byte order in the dex that matches the host OS's will likely result in a performance gain as the VM can cast more efficiently.
- JosephRedfern 11y ago
  That's true - do you suppose that this flag might be used if an app developer was targeting a specific CPU architecture, then? I guess it could be argued that if you're that concerned about performance and know your target architecture, that it might be worth going native rather than running on a VM.
  - yincrash 11y ago
    This is just a guess, but I think the odex pass on dalvik switches the endianness to the architecture's native.
danfuzz 11y ago
You can blame me for those wasted four bytes (or, perhaps, that wasted terabyte in the aggregate). The original idea was that on big-endian machines, the resulting .odex would be endian-swapped compared to the original .dex, and this field would provide a reasonably-blatant indication. This would probably help with debugging more than anything else (maybe help with security, but not much), because there's no reason anyone would drop a little-endian .odex file on a big-endian machine (or a big-endian one on a little-endian machine). We wrote (most of?) the code to get the vm working on big-endian systems, but within Google we never shipped any big-endian hardware AFAIK. I have my doubts that anyone ever did.

davtbaum 11y ago

Even though the bytecode is being executed on a VM, the VM itself has been ported to the architecture, which has a native endianness. Byte order in the dex that matches the host OS's will likely result in a performance gain as the VM can cast more efficiently.

JosephRedfern 11y ago
That's true - do you suppose that this flag might be used if an app developer was targeting a specific CPU architecture, then? I guess it could be argued that if you're that concerned about performance and know your target architecture, that it might be worth going native rather than running on a VM.
- yincrash 11y ago
  This is just a guess, but I think the odex pass on dalvik switches the endianness to the architecture's native.

danfuzz 11y ago

You can blame me for those wasted four bytes (or, perhaps, that wasted terabyte in the aggregate). The original idea was that on big-endian machines, the resulting .odex would be endian-swapped compared to the original .dex, and this field would provide a reasonably-blatant indication. This would probably help with debugging more than anything else (maybe help with security, but not much), because there's no reason anyone would drop a little-endian .odex file on a big-endian machine (or a big-endian one on a little-endian machine). We wrote (most of?) the code to get the vm working on big-endian systems, but within Google we never shipped any big-endian hardware AFAIK. I have my doubts that anyone ever did.