4 ms·

And not all of those enhancements are unique to OpenJDK. ART can already emit direct FFI calls from Java, for example ( https://android.googlesource.com/platfor

And not all of those enhancements are unique to OpenJDK. ART can already emit direct FFI calls from Java, for example ( https://android.googlesource.com/platform/art/+/86c8752f64629325026945cd4eabd1dcea224acb https://android.googlesource.com/platform/art/+/86c8752f6462... ) ART has also long had hooks for native allocations to influence GC pressure ( https://android.googlesource.com/platform/art/+/987ccff https://android.googlesource.com/platform/art/+/987ccff ) , which have improved to become automatic via malloc hooks & use phantom references for cleanup ( https://www.youtube.com/watch?v=7_caITSjk1k https://www.youtube.com/watch?v=7_caITSjk1k ) Similarly Loom isn't necessarily useful for client-side apps, as coroutines already fit that role and full green threads isn't useful. Most likely Loom would be a regression for mobile apps, as keeping key threads responsive is more important than maximizing throughput. And it definitely isn't going to be as tuned for things like big.LITTLE out of the gate as the existing Linux scheduler is. The only ~significant area of issue here is those trying to build commonly portable Java libraries. But there's not much in common in practice here, and that shouldn't be the singular deciding factor. But the meta-point here is how much of the "use openjdk instead!" crowd is simply overly familiar or buying in to OpenJDK hype & general JEP awareness, and simply isn't following along with what's going on with ART on the other side of things? ART isn't a bad runtime, after all, it's actually quite good. And it's had a lot of useful things that OpenJDK doesn't or only just recently got (like specifying what was null when an NPE is thrown - ART's been doing that for years)

pron 6y ago
Sure, but my point was about similarity/compatibility. It might be the case that Android has suitable alternatives to Java's features, and it's possible that they're even more suitable for Android's needs, but the point is that while the two platforms were quite similar ten years ago, and a single language could target both with few if any tradeoffs, this is increasingly becoming tenuous as the two platforms become dissimilar in fundamental aspects. A language that attempts that will increasingly find itself needing to make tradeoffs that it didn't need to, say, five years ago, or even today.
thu2111 6y ago
ART can indeed ignore Loom, or better just map the virtual thread API to regular threads. It'd not work well for things like generators but those aren't a target of Loom at the moment anyway. The lack of other features in ART does hold things back though. The list of bytecode and API features that ART doesn't have keeps growing and some would be useful on mobile. Panama will add a better FFI and a SIMD API, when will Android get that? Never? That would be a pity. What about Truffle/Polyglot? What about some of the neat tricks allowed by proper invokedynamic? Other than licensing I do wonder why Google can't just bring the nice bits of ART across to HotSpot. It would save library developers a lot of heartache.

pron 6y ago

Sure, but my point was about similarity/compatibility. It might be the case that Android has suitable alternatives to Java's features, and it's possible that they're even more suitable for Android's needs, but the point is that while the two platforms were quite similar ten years ago, and a single language could target both with few if any tradeoffs, this is increasingly becoming tenuous as the two platforms become dissimilar in fundamental aspects. A language that attempts that will increasingly find itself needing to make tradeoffs that it didn't need to, say, five years ago, or even today.

thu2111 6y ago

ART can indeed ignore Loom, or better just map the virtual thread API to regular threads. It'd not work well for things like generators but those aren't a target of Loom at the moment anyway. The lack of other features in ART does hold things back though. The list of bytecode and API features that ART doesn't have keeps growing and some would be useful on mobile. Panama will add a better FFI and a SIMD API, when will Android get that? Never? That would be a pity. What about Truffle/Polyglot? What about some of the neat tricks allowed by proper invokedynamic? Other than licensing I do wonder why Google can't just bring the nice bits of ART across to HotSpot. It would save library developers a lot of heartache.