From daniel.smith at oracle.com Fri Nov 8 21:04:51 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 8 Nov 2019 14:04:51 -0700 Subject: Class validation cleanups Message-ID: <5AB35A30-E754-4C90-AB56-3AAF206CC23B@oracle.com> I've put together some JVMS change proposals to improve its specification of the class validation process, including class loading, format checking, and verification. These are independent of Valhalla, but lay the groundwork for additional changes to the spec. They address things like: - How are and methods constrained? - Can array types be field/method receiver types? (Yes, it turns out.) - When do we enforce the 'final' modifier on classes/methods? - Which attributes are validated, and when? - How does class loading handle anomalous situations? For format checking refinements: https://bugs.openjdk.java.net/browse/JDK-8233854 http://cr.openjdk.java.net/~dlsmith/class-validation/class-validation-20191107/specs/format-checking-jvms.html For class loading cleanup: https://bugs.openjdk.java.net/browse/JDK-8233861 http://cr.openjdk.java.net/~dlsmith/class-validation/class-validation-20191107/specs/class-loading-jvms.html For attribute validation: https://bugs.openjdk.java.net/browse/JDK-8233863 http://cr.openjdk.java.net/~dlsmith/class-validation/class-validation-20191107/specs/attribute-validation-jvms.html The last is the most disruptive, since we're proposing simply ignoring some attribute contents that has traditionally been parsed and validated. I think it may be reasonable to create a JEP for that piece. From david.simms at oracle.com Wed Nov 20 17:57:54 2019 From: david.simms at oracle.com (David Simms) Date: Wed, 20 Nov 2019 18:57:54 +0100 Subject: Valhalla EG 20191120 Message-ID: <82774259-30ea-0ce2-daaa-7ad9b5a52e4a@oracle.com> - Brian ??? - Expanding on the previous discussion on the Eclair model... ??? - ...rather than having three things: references, inlines and primitives ??? ??? - lets subsume primitives (to be part in inline values) ??? ??? - ...so we get: reference values and inline values ??? - Inline Values ??? ??? - primitives and inline classes ??? ??? - Represented and stored directly ??? - Reference Values ??? ??? - Pointers to class instances, arrays and null ??? ??? - Represented and stored as indirections ??? - More detail/write-up coming - Remi: wait, is like MVT ? - Brian: in the language yes, but not in the VM ??? - Conversion is "free" ??? - There are still Q-types, but L/Q-type (dual naming) is gone ??? - "Companion interface" - DanH: int vs interface (pox) - Brian: ??? - The language compiler will be doing the conversion i <=> Qjava.lang.int ??? - There is a migration story for migrating primitives / Optional... ??? - ...write-up need to be able to debate the finer points - Remi: I kinda like it - Brian: ??? - LWorld type system is good for the VM, but has short comings for the language ??? - ...so let's use something different in the language model, and use translation to do the work to keep the VM out of trouble - Remi: int would have a "ref projection" - Brian: yes, automatic and total - Remi: must the VM provide the ref projection ? - Brian: no the language compiler can provide it, ??? - or a migration story might involve some manual specified type - Remi: ref projections used where - Brian: circularity, null-ability, compatibility ??? - We think you always have a reference projection for inline types - Brian: figuring out where to put the responsibility ??? - how much in javac vs VM ? - Remi: some playing with eclair model, has empty - Brian: reference projection can simply be an interface - Remi: how do we have an "inline record" (abstract record) - Brian: short answer: "abstract record" become interface ??? - ValObj / RefObj are interfaces ??? - Interfaces vs abstract: ??? ??? - current thinking Interfaces offer few problems (needs more work) - Remi: does volatile work in the prototype ? - Simms: nope - Remi: VarHandle support for "non-volatile" inline ??? - Yeah, should throw exception ??? - Can we get volatile field decl into the prototype ? ??? ??? - Fred: sure, we'll write up a few bug - Remi: ??? - equality "==", shall we make lambda inline class (sentinel problems) - Brian ??? - sure, might be worth looking into, to get people slightly more happy with notion equality for lambda ??? - Might have some performance implications "fat lambdas", worth looking at though Happy Thanksgiving !