[regression] 3.0 x86_64 on some processors

[Ildar Mulyukov]

Hello fellow Androids!

Following updates I moved to the first 3.0 beta version and found the regression:

While the x86_64 version 2.x (based on L) ran quite good on my old Pentium T2390 notebook, the version 3 (M) just failed. Tombstones witness that zygote can't start, SIGFAULT-ing.

That may be the result of newer opt flags and/or switching off some emu instructions.

i586 version ran fine.

You can contact me if you need more info.

Best regards, Ildar

[Ildar Mulyukov]

The problem persists with the latest beta. Jide doesn't care?

[hypot...@gmail.com]

Is that with a clean data.img or the same one from 2.x?

[Ildar Mulyukov]

Clean.

[whitet...@gmail.com]

It seems I experience the same issue with only 32bit Remix 3 working on my old Toshiba with Pentium CPU and on a Compaq CQ45 with AMD-E1 CPU:

Can I assume this is due to build flags as well?

dmesg extract from the latter:

<13>[   35.153369] init: Starting service 'bootanim'...
<6>[   40.820688] main[1672]: segfault at 70 ip 00007f05569ba7b0 sp 00007ffc2ede6768 error 4 in libandroidfw.so[7f0556995000+40000]
<13>[   40.829070] init: Service 'zygote' (pid 1672) killed by signal 11
<13>[   40.829093] init: Service 'zygote' (pid 1672) killing any children in process group

and tombstone extract

Build fingerprint: 'Jide/remix_x86_64/remix_x86_64:6.0.1/MOB30Z/B2016083002:user/release-keys'
Revision: '0'
ABI: 'x86'
pid: 2323, tid: 2323, name: main  >>> zygote <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x44
    eax 00000000  ebx f75e4b04  ecx 00000000  edx 00000002
    esi 72726100  edi 12c17ca0
    xcs 00000023  xds 0000002b  xes 0000002b  xfs 00000007  xss 0000002b
    eip f7160814  ebp 6fbdb418  esp fff482ec  flags 00210286

backtrace:
    #00 pc 00022814  /system/lib/libandroidfw.so (_ZNK7android8ResTable13getTableCountEv+4)
    #01 pc 000c49e9  /system/lib/libandroid_runtime.so
    #02 pc 02404e34  /system/framework/x86/boot.oat (offset 0x1e97000)
    #03 pc 0009994f  /data/dalvik-cache/x86/system@framework@boot.art

 

[whitet...@gmail.com]

EDIT: dmesg & tombstone taken from a failed boot with Compaq CQ45 (AMD E1 CPU)
but Toshiba shows the same dmesg errors

[Ildar Mulyukov]

Yep :(
I wonder if someone tried pure Android-x86 M to have this issue.
Ildar.

[whitet...@gmail.com]

Just tried pure Android_x86_64-6.0-r1 (latest) and the same problem appears. Also tried nightly from http://dev-io.ro/nightly-builds/ but had different problem with opcode failed in libm.so ...

[Ildar Mulyukov]

Guys,
the developer gave the answer:

понедельник, 19 сентября 2016 г., 9:48:23 UTC+6 пользователь Chih-Wei Huang написал:

Looks like your CPU is not supported.
In doubt, check /proc/cpuinfo (cat /proc/cpuinfo)
to see if it contains all required x86 instructions
listed in

https://developer.android.com/ndk/guides/abis.html

So we seem to stuck with Lollypop. Not so bad after all.

[Evan Langlois]

The official Android API specs specifically states that sse4 instructions (among others) must be supported by your processor in order to use the x86_64 ABI.  The T2390 does not support these instructions, so you should be using the x86 ABI, not x86_64.  

Please don't believe the hype that x86_64 will be amazingly faster.  While some benchmarks will show a difference in some graphics intensive operations that need to move 64 bit datatypes in a single operation, or some complex math, the majority of code isn't using these operations.  When such operations are required, the compiler substitutes two 32-bit operations in place of the single 64 operation (actually this can be 3 or 4 instructions, not 2 as an extra shift or flag check might be added).  At nearly 2 billion instructions per second, you won't notice!

What will make a difference is that once you run real code and not just benchmarks, you may find 64 bit code to be SLOWER!  The reason is that benchmarks run a small amount of code in a tight loop that fits entirely in your CPU cache.  Real code has to deal with cache misses requiring a cache fill across the relatively slow bus to DRAM.  The processor has to stop and wait for the cache line to fill (this is the basis of hyper-threading as the core will run the 2nd thread while the first is waiting on DRAM).  With a 64 bit ABI, your pointers will grow from 4 bytes to 8 bytes.  Every pointer and even many standard data-types will double in size.  Registers that could formerly be treated as two 32-bit registers now are a single 64 bit register, so these valuable resources diminish while code size increases.  Larger code and data means that less will fit inside the smaller cache of older CPUs, and your chance of cache misses goes up, and your system slows down.

TL;DR ... You should use 32-bit code on these systems, not 64 bit.  The only drawback is if you have more than 3GB of RAM (and even then, Android should support PAE and give you up to 64GB of RAM).

UPDATE:  Sorry to everyone following if you got multiple posts.  Reading this on a non-chrome browser gives a totally different interface that is horribly buggy!   Yay Google!