9 ms·
Value Type Hygiene
- vvanders 8y agoHappy to see value types making their way, however I'd put good money on not seeing this in Android until 2030 at the earliest.
- Larrikin 8y agoIn the Android world, it's quickly becoming what Kotlin supports.
- sureshv 8y agoStill need JVM support of value types for this to make sense.
- jayd16 8y agoAndroid doesn't use the JVM. Hell, it doesn't even really use a VM any more.
- pjmlp 8y agoSure it does, ART was AOT only during Android 5 and 6. Android 7 brought the VM back. Now it uses an interpreter hand written in Assembly that gathers PGO info for the JIT, which also performs PGO data gathering, then only the hot bits are AOT compiled to native code, when the device is idle. Any change on the execution path or updates trigger the execution process from the beginning.
- wolf550e 8y agoI didn't know that. Here are the docs: https://source.android.com/devices/tech/dalvik/jit-compiler https://source.android.com/devices/tech/dalvik/jit-compiler
- pjmlp 8y agoThe docs are outdated, Android P is bringing sharing of PGO data across devices via the Play Store. https://www.youtube.com/watch?v=Yi9-BqUxsno https://www.youtube.com/watch?v=Yi9-BqUxsno
- jayd16 8y agoI'm going to stand by my statement of "not really a vm." Calling it a plain vm when the goal is to run as much AOT code as possible is too misleading.
- pjmlp 8y agoI call it whatever the CS theory of programming language says. And from that point of view, ART on Android 5/6 was a runtime, turned into a VM on Android 7. From your point of view, the CLR is also not a VM.
- pjmlp 8y agoThe Android world only has to loose by dropping compatibility with Java libraries written in Java 9 and newer versions. Or do you think now everyone is going to rewrite their Java libraries into Kotlin, using JVM 8 only features?
- niftich 8y agoWhat a fascinating design constraint: to retrofit a useful feature into the Java ecosystem while keeping as many things backwards-compatible as possible. This proposal has a much stronger answer to backward compatibility than the previous one, by letting all ported builtin classes keep the same descriptor in the bytecode. The catch is that each class file will now declare which of the types it imports are ValueTypes, and which aren't. Java's strong commitment to bytecode-level backwards-compability is sometimes to the detriment of its feature-set (e.g. non-reifiable generic types due to type erasure), but this commitment is a large contributor to the platform's success.
- kjeetgill 8y agoFor what it's worth, Brian Goetz doesn't see type-erasure as a such a failure and defends the design choice[0]. [0]:https://m.youtube.com/watch?v=TkpcuL1t1lY https://m.youtube.com/watch?v=TkpcuL1t1lY
- noelwelsh 8y agoI'd say the mainstream programming language theory view is that type erasure is the correct approach. See https://en.wikipedia.org/wiki/Parametricity https://en.wikipedia.org/wiki/Parametricity
- eecc 8y agoPardon my ignorance but I don’t see how the Wikipedia link supports your statement. Can you please elaborate?
- noelwelsh 8y ago"parametrically polymorphic" == has a generic type. So a function foo[A](x: A) = ??? // Implementation hidden for now is parametrically polymorphic, where A is the generic type (or type variable). The principle of parametricity says that `foo` should act in the same way no matter what type of value it is called with. Type erasure ensures this, because it prevents `foo` from inspecting the (reified) type at runtime. If types are not erased then `foo` can behave differently when given, say, a `String` or an `Int`. Why is parametricity important? It makes code easier to reason about. Parametricity means no special cases to remember. It makes everything more uniform and simpler. In fact there is only one valid implementation of `foo` above, and this is the identity function. foo[A](x: A) = x Looking just at the type signature of `foo` tells you everything there is to know about it---which is quite remarkable! This reasoning principle is sometimes called "free theorems".
- tom_mellior 8y agoSilly quick question: What is the "L-world" discussed here?
- foota 8y agoI think this has to do with the class file representation of value types, where the l world is more similar somehow to the current state whereas the q world introduces major differences.
- kjeetgill 8y agoThe letter L is used in the JVM bytecode specification to refer to objects (as opposed to primitives or arrays). You'll often see that notation when using jmap or javap. https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.3.2 https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.ht...
- tom_mellior 8y agoThanks! I'd seen that notation before, but I didn't connect it to this context.
- willvarfar 8y agoI can't wait for Value Types to land! The contortions my code has to go through to fit in RAM and avoid fighting the garbage collector drives me nuts. Problems that might fit in a few megabytes in, say, C/C++ can take gigabytes in JVM. I have always looked at the C# structs with envy. Rah rah I hope the authors peek on HN and see that their work has baying fans :)
- karianna 8y agoI help run OpenJDK advocacy - and yeah we notice . The authors aren’t always able to jump in on threads but we collate feedback for them
- pjmlp 8y agoC# has much more than only structs. You can do manual memory management, GC free code blocks and there is unsafe. Additionally C# 7.x has safe stack allocation, spans, references to stack allocated data. Looking forward to have some of those goodies in Java as well.
- zamalek 8y agoValue types are stack allocated types (unless they are a member of a reference type). You might be referring to stack-only value types, which are prevented from being copied to the heap.
- pjmlp 8y agoI am referring to array values. Up to 7.3 you could only stack allocate arrays (alloca() style) inside unsafe code blocks. Starting with 7.3 you can safely stack allocate array of value types.
- apta 8y ago> Additionally C# 7.x has safe stack allocation, spans, references to stack allocated data. How much of those are the direct result of having value types in the language? As far as the other features you mentioned, it would be nice to have them in the JVM as well.
- lsd5you 8y agoPresumably I'm missing something, but are they trying to do something more than just Boxing value types? (Specialization?) I cannot see how legacy classes would be impacted if Boxing was used, nor quite why it is going to be so difficult. Boxing would seem to deliver most of the benefits (i.e. the ability to do things in a memory efficient manner in new code).
- dgreensp 8y agoYes, the point is to not box them.
- lsd5you 8y agoYes, in ArrayLists ... etc., but if you want compact values on the stack, or compact value data structures you don't need this. I feel like 80% of the solution (and one which is likely future compatible) is going begging whilst they worry about nice to haves.