https://kotlinlang.org logo
#compiler
Title
# compiler
u

ursus

02/06/2023, 11:58 PM
As a android developer that only writes kotlin code. what
jvmTarget
should I use? Is there anything to gain when bumping ˙1.8` to
11
, when java language features are irrelevant to me? Performance?
Kotlin stdlib did make some different APIs available with different targets, such as https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/use.html (1.7+), I can't think of anything that's only 9+ though
u

ursus

02/07/2023, 1:52 AM
so, in theory by bumping to jvm11, I get a few new instructions, making it more performant in the given use cases?
e

ephemient

02/07/2023, 1:53 AM
that's really more of an Android question than a Kotlin one
u

ursus

02/07/2023, 1:54 AM
sure, but if I were to target say jvm6, then my lambdas would be anonynmous classes, right? by being jvm7 target I'd get the invokedynamic instruction making it more optimized do I get it right?
e

ephemient

02/07/2023, 1:55 AM
in general JVM terms, the invoke-dynamic stuff is results in smaller generated code (with possibly slightly faster build times), but it basically trades off startup/runtime time. so there's really not much measurable difference
in Android terms, you can't use invoke-dynamic if you have minSdk<26; if your code does, D8 will desugar it back to classes
u

ursus

02/07/2023, 1:59 AM
I'm mostly writing because of a library author who bumped the library to jvm11, and now I'm not sure what to do Are the reasons mostly "purity", because java8 is EOL?
is there a map of android api vs java version? can't seem to find it does jvm target imply a minSdk as well?
e

ephemient

02/07/2023, 2:02 AM
the Android API doesn't map to Java versions, period
u

ursus

02/07/2023, 2:02 AM
nn I mean what version of java does each platform version include
e

ephemient

02/07/2023, 2:02 AM
Android S has a few Java 11 APIs but not all. Android T will add more Java 11 APIs, Android U will add some Java 17 APIs, but none of it is going to exactly match
that's just on the API side. on the bytecode side, DEX bytecode versions don't match with Java bytecode versions either
u

ursus

02/07/2023, 2:04 AM
okay so what is my jvmTarget limited by .. by what is D8 able to ingest?
e

ephemient

02/07/2023, 2:04 AM
pretty much, yes
u

ursus

02/07/2023, 2:05 AM
so why did he chose 11, he could have gone even for 17, no?
e

ephemient

02/07/2023, 2:05 AM
there are some Java 11 bytecode changes that d8 can't handle, such as https://openjdk.org/jeps/309, but mostly it works
actually looks like that particular case is fixed https://issuetracker.google.com/issues/178172809
u

ursus

02/07/2023, 2:07 AM
so would you say the reason to increase the jvm target just academic, as to "move the industry forward" and not depend on EOL software?
e

ephemient

02/07/2023, 2:07 AM
Android Studio Electric Eel ships with JBR 11 and Android Studio Flamingo will ship with JBR 17, so it's not like it's depending on EOL software anyway
u

ursus

02/07/2023, 2:08 AM
whats a jbr
jre?
u

ursus

02/07/2023, 2:09 AM
I see. But the author bumped the version of the runtime as well, not just the compiler plugin
(its a kotlin ksp processor + some small runtime stuff for the moshi json parser - giving it ability to serialize nested classes via the annotations, which you cannot do with the stock library's codegen) bumping the compiler I would understand, as that runs on my machine, same as AS, but the runtime, that I didn't get) But I now tried to raise the jvm target in my android application, and everything seems to work fine Soo..idk
e

ephemient

02/07/2023, 2:15 AM
bumping the target in the compiler is actually possibly more annoying for non-Android users: Gradle still supports running on Java 8, and when it does, it can't load plugins built for newer targets
but for Android that doesn't matter because the Android Gradle Plugin needs to run on Java 11+ anyway
u

ursus

02/07/2023, 2:20 AM
hmm okay so is there any guarantee jvm11 target works on say api21 android?
e

ephemient

02/07/2023, 2:22 AM
that's really an Android question. but it's not even guaranteed that all Java 8 code works - in fact, not all of it does. but a useful subset of it does. ditto Java 11 and 17.
j

jw

02/07/2023, 3:38 AM
in Android terms, you can't use invoke-dynamic if you have minSdk<26; if your code does, D8 will desugar it back to classes
Android does not ship LambdaMetaFactory. Even if you have min API 33 you get lambdas desugared to classes at dexing time.
so would you say the reason to increase the jvm target just academic, as to "move the industry forward" and not depend on EOL software?
yes. there's no reason to do this in this specific instance.
e

ephemient

02/07/2023, 4:02 AM
Android does not ship LambdaMetaFactory. Even if you have min API 33 you get lambdas desugared to classes at dexing time.
oh, I saw https://cs.android.com/android/platform/superproject/+/master:libcore/ojluni/src/lambda/java/java/lang/invoke/LambdaMetafactory.java but I never checked if it's actually on device
u

ursus

02/07/2023, 4:06 AM
Im still kinda confused, what kind of "java" is on devices then? is it basically java 6?
j

jw

02/07/2023, 4:07 AM
no. it is an entirely custom VM with OpenJDK sources plucked from many different versions of Java compiled as part of the Android OS
u

ursus

02/07/2023, 4:08 AM
if so then why no native lambdas?
j

jw

02/07/2023, 4:08 AM
it is like 99% Java 6, 95% Java 8, and like 91% Java 11
because the custom VM is really bad at spinning bytecodes at runtime whereas the JVM is really good at it
e

ephemient

02/07/2023, 4:08 AM
and a number of Android-specific changes to the OpenJDK implementations too
u

ursus

02/07/2023, 4:13 AM
got it, so java lambda syntax was a developer quality of life thing, therefore we bumped jvm target to 1.7, therefore d8 desugar kicks to enable that which means it only makes sense to raise jvm target to get new language features which is however irrelevant for kotlin
e

ephemient

02/07/2023, 4:17 AM
(I know it's not that simple but) if GraalVM native-image can handle LambdaMetaFactory and StringConcatFactory (at least the way the compiler uses them), why can't ART handle that too blob shrug
anyhow, in my projects, I find the biggest reason to bump JVM targets is when dependencies do
j

jw

02/07/2023, 4:18 AM
it can handle it. they choose not to
u

ursus

02/07/2023, 4:19 AM
anyhow, in my projects, I find the biggest reason to bump JVM targets is when dependencies do
java source dependency, right? kotlin doesnt really care right?
e

ephemient

02/07/2023, 4:20 AM
Gradle cares, and also Kotlin cares if you want to use
inline fun
j

jw

02/07/2023, 4:20 AM
the source version is the version of Java source being compiled. the target version is the bytecode version embedded in the classfile that you consume
u

ursus

02/07/2023, 4:24 AM
but that applies mostly to java world no? i.e. to ingest java8 source and output java6 bytecode on android it seems it doesnt matter what version the bytecode is, only what d8 can handle?
or am I making it easier for d8 if I were to output say java6 bytecode?
j

jw

02/07/2023, 4:25 AM
There's no reason to use java6 or 7 anywhere.
kotlinc
won't even emit Java 6 bytecode anymore and neither will
javac
u

ursus

02/07/2023, 4:27 AM
okay then say source 11, target 8, i.e. to make them not the same number
j

jw

02/07/2023, 4:28 AM
javac
stopped supporting different source and target versions in... Java 6? They have to match now.
u

ursus

02/07/2023, 4:28 AM
I see.
j

jw

02/07/2023, 4:28 AM
In fact, you shouldn't even use source/target anymore with
javac
. Since Java 9 there's a
-release
flag which sets the bootstrap classpath (basically the built-in APIs), the source, and the target with a single number
it allows any version of
javac
to cross-compile to other versions. The latest, 19, supports 8-19
actually it may still support 7. i honestly can't remember, but it definitely doesn't support 6 for a few versions now
e

ephemient

02/07/2023, 4:31 AM
kotlinc has
-Xjdk-release
(but neither it nor
--release
are relevant for Android since it's not using the JDK's classpath anyway)
u

ursus

02/07/2023, 4:32 AM
so I should not explicitly set these?
Copy code
compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
j

jw

02/07/2023, 4:33 AM
that looks like the Android ones. the default is 8 so that's not really doing anything
there's also this whole complication where Gradle doesn't have APIs to set
-release
and so you still have to set source/target
it will infer that you're trying to cross-compile and use
-release
u

ursus

02/07/2023, 4:36 AM
I see. Btw why would they choose not to do native lambdas? Is the anon class instantiation not a penalty?
Or did they rather make instantiation cheaper
j

jw

02/07/2023, 4:38 AM
the justification is that things like vertical and horizontal class merging offers a greater size savings and better performance
u

ursus

02/07/2023, 4:39 AM
oh so the invokedynamic is just about physical code size?
j

jw

02/07/2023, 4:39 AM
otherwise you have to spin all these classes at runtime and persist that dalvik bytecode somewhere and then load it back in so it can participate in the interpreter/JIT/AOT pipeline. the CPU/battery overhead is reportedly much higher than just doing it at compile-time when you have a computer plugged into a wall with infinite CPU
u

ursus

02/07/2023, 4:39 AM
I though it somehow avoided instantiation
j

jw

02/07/2023, 4:39 AM
no change. it's always a class.
u

ursus

02/07/2023, 4:41 AM
I see, devilish question.. does a VM make sense at all nowadays on Android, the way things shaped up?
I always though JVM was about multiplatformness
write java source, produce one binary and then push all the complexity to vm vendors to implement platform native
now, its a single OS, single cpu abi.. so..does it make sense?
e

ephemient

02/07/2023, 4:43 AM
Android is still multiplatform (x86, arm, riscv)
u

ursus

02/07/2023, 4:43 AM
obviously hindsight is 2020 and library ecosysyem is a big thing
yea but is it really? if x86 is 1% Ill eat my hat 😀
e

ephemient

02/07/2023, 4:44 AM
count how many chromebooks with play store support there are
j

jw

02/07/2023, 4:44 AM
nvidia shield and chromebooks
yeah
e

ephemient

02/07/2023, 4:44 AM
u

ursus

02/07/2023, 4:46 AM
werent android apps on chromebooks sort of a sideeffect? cant be 1% of all android users
e

ephemient

02/07/2023, 4:47 AM
I might agree that creating your own VM doesn't make as much sense now as it did back when Android started
u

ursus

02/07/2023, 4:48 AM
I mean Im not sure what else should they have chosen, c++ is for aliens, dynamicly typed languages are the worst seems every OS creates its own language, c#, swift
maybe keep the java source because of libraries and deveopers and skip the vm and go straight to native from bytecode but that would blow the binary size up right? ios binaries are like 10x
e

ephemient

02/07/2023, 4:52 AM
bytecode is typically smaller than native code, yes. and we have DEX for a variety of reasons, partly to be even more compact than Java bytecode (but also because J2ME is rubbish and J2SE licensing was not as good back then, I believe)
j

jw

02/07/2023, 4:53 AM
yeah register-based bytecode saves a bunch of space compared to Java's stack-based bytecode
u

ursus

02/07/2023, 4:55 AM
and to make use of all the size gains, lets pull in 30 dependencies 😀
j

jw

02/07/2023, 4:55 AM
apps were really small until the post-Honeycomb era
e

ephemient

02/07/2023, 4:58 AM
stats I found for 2021: 0.98 billion android devices sold, 37.3 million chromebooks even if a majority of those aren't x86 or don't support Android, I think there's a pretty good chance that's over 1%
u

ursus

02/07/2023, 5:02 AM
but I believe bundling everything with the app was instrumental, like now, single compose version all the way back to api21 .. sometimes I have to work on ios and they never adopt new stuff, forbid its a bank of sorts, youll be lucky to even use swift because the cant bump from ios6
j

jw

02/07/2023, 5:03 AM
that was also a post-Honeycomb change, although it took Google a few years to really understand how much they needed to unbundle
u

ursus

02/07/2023, 5:04 AM
but now you get a compose bytecode copy per app right? I think play store has a thing where they could share the library
j

jw

02/07/2023, 5:05 AM
there is no sharing
u

ursus

02/07/2023, 5:05 AM
but how would that work even, different process/heap?
j

jw

02/07/2023, 5:06 AM
there are too many versions to share, and it breaks your ability to run R8. it was proposed about 6 years ago as a potential solution but the problem has only gotten worse that it's effectively impossible. you would just be wasting space.
u

ursus

02/07/2023, 5:08 AM
yea, only downside for say compose is the debug performance, always catches me off guard how choppy the scrolling it, that taught me to ignore it, and now I wouldnt even spot a perf. issue if I had one 😀
e

ephemient

02/07/2023, 5:10 AM
https://chromium.googlesource.com/chromium/src.git/+/master/docs/android_native_libraries.md does manage to share code into different apps, but it's special
u

ursus

02/07/2023, 5:10 AM
simply building release builds is still not up to par with views as they say
only when JIT kicks in then then its nice
lol monochrome 💯, and they say naming is hard
Aaaand as we were talking about it, java 17 features introduced in android 14 do we get real pattern matching now? record classes are just data classes, not real value types right?
e

ephemient

02/08/2023, 10:23 PM
pattern matching is a Java language feature, doesn't have any new bytecode or APIs. Android doesn't need to do anything.
records need to be desugared but d8 can do it. Android version doesn't matter. https://issuetracker.google.com/issues/197081367
u

ursus

02/09/2023, 12:05 AM
oh I see, I thought kotlin was waiting for some jvm features to implement pattern matching
j

jw

02/09/2023, 12:06 AM
Efficient pattern matching requires invokedynamic and constant dynamic
u

ursus

02/09/2023, 12:07 AM
efficient in dimension of bytecode size?
u

ursus

02/09/2023, 12:11 AM
btw how far along are real value types in jvm?
I remember there being talk, then it died down, then records came up .. did they ditch it?
e

ephemient

02/09/2023, 12:16 AM
https://jdk.java.net/valhalla/ still work in progress
u

ursus

02/09/2023, 12:23 AM
if they were implemented, and assuming there are no new instructions added to the bytecode grammar, how would that then look like on android? We would only need D8 to desugar it?
now that I think about it, why do we even need D8 😄 in order to desugar new bytecode, but why, since say
invoke dynamic
is unknown to ART?
okay I'll rephrase, if there is new bytecode, android will evaluate whether they can desugar, however if they cannot, then ART changes are needed, and therefore it implying minSdk?
e

ephemient

02/09/2023, 12:26 AM
invokedynamic can potentially build new things at runtime. its use in compiled lambdas is effectively static, so d8 can desugar it. other uses, not so much.
u

ursus

02/09/2023, 12:28 AM
yea okay so they chose to not implement invoke dynamic, because they can get away with not implementing it but if a key feature like value types is impossible with their current instruction set, then what?
e

ephemient

02/09/2023, 12:29 AM
valhalla is still in flux; the changes so far aren't so much to the bytecode instructions, but instead change the object model
u

ursus

02/09/2023, 12:31 AM
I see, but lets assume my assumption, i.e. it being impossible in current ART grammar, then the only solution is to build it into the runtime, and therefore implying a new minSdk?
e

ephemient

02/09/2023, 12:31 AM
yes
u

ursus

02/09/2023, 12:32 AM
but there was the thing .... project mainline or something? probably could distribute it bit lower, but I think that was android 9+
but yea, thanks for clarifying!
e

ephemient

02/09/2023, 12:34 AM
there isn't a way to declare "my app only works on devices with this APEX module version or higher", afaik
u

ursus

02/09/2023, 12:34 AM
so project mainline is not everywhere? atleast everywhere with play store?
btw does ART (lates version) have
invokedynamic
at all? I'm hearing conflicting things
j

jw

02/09/2023, 1:27 AM
yes they're called invoke-custom and invoke-polymorphic
u

ursus

02/09/2023, 1:30 AM
and those are 26+?
j

jw

02/09/2023, 1:31 AM
probably 24. i would have to check
u

ursus

02/09/2023, 1:32 AM
26
okay so they did introduce new bytecode in 28, but when implementing lambdas, they chose not to use it as desugared bytecode was somehow superior?
j

jw

02/09/2023, 1:35 AM
well, they added support for lambdas in like 2015 with the Jack compiler
and in order to target the versions of devices people actually wanted to use they had no choice but to desugar them to classes
u

ursus

02/09/2023, 1:36 AM
I do get the desugaring bit pre-26, but why desugar on the runtime that effectively supports invokedynamic
j

jw

02/09/2023, 1:37 AM
i think we already covered that. 1. the OS doesn't ship LambdaMetafactory 2. the performance of the bytecode instruction is slower than classes 3. classes can be horizontally and vertically merged
u

ursus

02/09/2023, 1:39 AM
I see, thanks!
tangent -- if I were to update to jvm target version 11, if it compiles then it should all work right? or do I need to test runtime as well?
j

jw

02/09/2023, 1:41 AM
if that is all you are changing then i suspect you're fine if it compiles
u

ursus

02/09/2023, 1:42 AM
yes no new java api usage, just the emitted bytecode change
kk thanks
78 Views