www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - GC.LDC2 on Android

reply Danny Arends <Danny.Arends gmail.com> writes:
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 ???
Sep 08 2020
parent reply kinke <kinke gmx.net> writes:
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.
Sep 08 2020
parent reply Danny Arends <Danny.Arends gmail.com> writes:
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-555146BAEC3641EAD156A00
13211307\libmain.so .dub\build\android-debug-linux.posix.android-aarch64.arm_hardfloat-ldc_2093-555146BAEC3641EAD15
A00213211307\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\li
arsd-official_jni.a ..\bindbc-gles\.dub\build\dynamicBC-debug-linux.posix.android-aarch64.arm_hardfloat-ldc_2093-B2DF1F93BE637030294C2E6219F26
9F\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-E89B5B92EC516794E9D7694E4062
205\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-44C0A0E484E57B7F1481E669A0811B6
\libBindBC_Loader.a -L--no-as-needed -L-landroid -L-ldl
-mtriple=aarch64--linux-android -shared -g
</snip>
Sep 08 2020
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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?
Sep 08 2020
parent Danny Arends <Danny.Arends gmail.com> writes:
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
Sep 08 2020
prev sibling parent reply kinke <kinke gmx.net> writes:
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
Sep 08 2020
parent Danny Arends <Danny.Arends gmail.com> writes:
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
Sep 08 2020