Hey all,

I'm porting my 3D engine to Android (so far most of the work is going smoothly). However, I had random crashes which I first suspected was due to how I do multi-threading, but after debugging it turns out that the Garbage Collector is the issue.

The crash always happens after entering the function:

_D2gc4impl12conservativeQw3Gcx11fullcollectMFNbbZm

The critical sections of the 3D engine are @nogc, but for some non-critical parts of the application I still use the GC.

Does anyone have any experience with using D on android, and using the garbage collector ???

On Tuesday, 8 September 2020 at 11:17:45 UTC, Danny Arends wrote:
> Does anyone have any experience with using D on android, and using the garbage collector ???

I've never run anything on Android myself, but I've gotten good feedback on AArch64 at least. Make sure to use a recent LDC, and especially to use the bfd linker, not gold or lld, as mentioned in various places.

On Tuesday, 8 September 2020 at 12:23:43 UTC, kinke wrote:
> On Tuesday, 8 September 2020 at 11:17:45 UTC, Danny Arends wrote:
>> Does anyone have any experience with using D on android, and using the garbage collector ???
>
> I've never run anything on Android myself, but I've gotten good feedback on AArch64 at least. Make sure to use a recent LDC, and especially to use the bfd linker, not gold or lld, as mentioned in various places.

Thanks,

I compile for AArch64, and am using the latest version 1.23.0


How can I figure out which linker is used ? When performing a dub build, it just mentions that ldc2 is used for linking

<snip>
Linking...
C:\ldc2-1.23.0-windows-multilib\bin\ldc2.exe -of.dub\build\android-debug-linux.posix.android-aarch64.arm_hardfloat-ldc_2093-555146BAEC3641EAD156A00213211307\libmain.so .dub\build\android-debug-linux.posix.android-aarch64.arm_hardfloat-ldc_2093-555146BAEC3641EAD156A00213211307\main.o C:\Users\Arends\AppData\Local\dub\packages\arsd-official-8.4.0\arsd-official\.dub\build\library-debug-linux.posix.android-aarch64.arm_hardfloat-ldc_2093-FB68B3ECD76B5B393C4A14B20D11A5C9\libarsd-official_jni.a ..\bindbc-gles\.dub\build\dynamicBC-debug-linux.posix.android-aarch64.arm_hardfloat-ldc_2093-B2DF1F93BE637030294C2E6219F2659F\libBindBC_GLES.a C:\Users\Arends\AppData\Local\dub\packages\bindbc-sdl-0.19.1\bindbc-sdl\.dub\build\dynamicBC-debug-linux.posix.android-aarch64.arm_hardfloat-ldc_2093-E89B5B92EC516794E9D7694E40626205\libBindBC_SDL.a C:\Users\Arends\AppData\Local\dub\packages\bindbc-loader-0.3.2\bindbc-loader\.dub\build\yesBC-debug-linux.posix.android-aarch64.arm_hardfloat-ldc_2093-44C0A0E484E57B7F1481E669A0811B65\libBindBC_Loader.a -L--no-as-needed -L-landroid -L-ldl -mtriple=aarch64--linux-android -shared -g
</snip>

On Tuesday, 8 September 2020 at 12:47:11 UTC, Danny Arends wrote:
> How can I figure out which linker is used ? When performing a dub build, it just mentions that ldc2 is used for linking

If you are using the d_android setup thing, it actually edits ldc2.conf so it uses the linker from the NDK. Did you do that step?

On Tuesday, 8 September 2020 at 12:47:11 UTC, Danny Arends wrote:
> How can I figure out which linker is used ? When performing a dub build, it just mentions that ldc2 is used for linking

You can add -v as dub 'linker' flag, that will make LDC show the actual cmdline. LDC v1.23 defaults to `-linker=bfd` for Android targets though. And now I actually remember that you should get a startup error in case the linker sections arrangement is a problem, so it's most likely not the linker.

The good feedback mentioned earlier, where the GC was apparently no problem: https://github.com/ldc-developers/ldc/issues/3461#issuecomment-648599814

On Tuesday, 8 September 2020 at 12:53:43 UTC, Adam D. Ruppe wrote:
> On Tuesday, 8 September 2020 at 12:47:11 UTC, Danny Arends wrote:
>> How can I figure out which linker is used ? When performing a dub build, it just mentions that ldc2 is used for linking
>
> If you are using the d_android setup thing, it actually edits ldc2.conf so it uses the linker from the NDK. Did you do that step?

I manually updated the ldc2.conf file, to point to the right NDK

On Tuesday, 8 September 2020 at 13:20:24 UTC, kinke wrote:
> On Tuesday, 8 September 2020 at 12:47:11 UTC, Danny Arends wrote:
>> How can I figure out which linker is used ? When performing a dub build, it just mentions that ldc2 is used for linking
>
> You can add -v as dub 'linker' flag, that will make LDC show the actual cmdline. LDC v1.23 defaults to `-linker=bfd` for Android targets though. And now I actually remember that you should get a startup error in case the linker sections arrangement is a problem, so it's most likely not the linker.
>
> The good feedback mentioned earlier, where the GC was apparently no problem: https://github.com/ldc-developers/ldc/issues/3461#issuecomment-648599814

Hmmm, very strange that I get crashes in the _D2gc4impl12conservativeQw3Gcx11fullcollectMFNbbZm...

I am using the SDL android-project as my project structure in Android studio. I am replacing the libmain.so which would normally be build from c/c++ with a libmain.so file created by D.

Everything compiles, deploys, and seems to work as expected.

Except for random crashes which went away after disabling the GC. It might be an interplay between Java, the SDL C trampoline code, and D threads or any of the other packages I am using (SDL_Mixer, SDL_Net, jni, d_android).

The weirdest thing is that after a segfault, the app closes, but swiping up will show the app as still running, clicking on it will re-start the app from scratch