Valhalla EG July 05, 2017 attendees: John, Vlad, Dan S, Dan H, Fred, Karen, Remi
AIs: All: review MVT JVMS http://cr.openjdk.java.net/~dlsmith/values.html All: review makeSecondaryClass: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2017-June/000286.html (for post-EA) All: review ConstantDynamic JVMS http://cr.openjdk.java.net/~jrose/jvm/condy-jvms-2017-0620.html MVT use case: Vlad: try to emulate Panama Vector superlongs as DVT to see box elimination - not yet ported any of Panama - next step: port Vector Intrinsics MVT JVMS: Review comments requested. Karen's notes: 1. 4.10.1.8 - I owe review that this is a cleanup of protected handling, with not behavior changes 2. 4.9.1, 4.9.2 There are a couple of areas we need to clarify ClassFileFormatError vs. VerifyError 3. question about just listing a subset of VCC rules? Dan S: just the enforcable subset 4. 5.3. eager vs. lazy derivation - are we allowed to do either? Dan Smith already sent far better notes/thoughts on this one: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2017-July/000324.html 5. One of the suggested changes was to move from using a classfile attribute to using a RuntimeVisibleAnnotation Maurizio reminded us later: hotspot implementation today already uses a RuntimeVisibleAnnotation: jvm.internal.value.DeriveValueType annotation so ask Dan Smith to modify the JVMS to match the annotation name? ==== ConstantDynamic JVMS: Review comments requested. Dan H: will send feedback during the next couple of weeks: Karen: we also owe feedback John: JVMS format experiment programatically - make more things like int.class not known to systemdictionary new class mirror - like a primitive mirror, not correspond to a class could make a shim over $Value real class with a different name note: java.lang.Class today needs a distinct class file perhaps use this for species "crass" (Karen request - need a new name - hard to hear the distinction between "class" and "crass") === Vector API experiments with MVT Vlad: Vector API - has boxing issues, JIT box elimination challenges initially tried heisenboxes now experimenting with MVT typed vectors ass VCC, use MethodHandles for operations - MH chains step 1: superlong primitives > 64 bit as VCC -> see what optimizations we can provide downside: API must as MH as well note: Ian Graves working on expression language for convenience to allow MH chains Toby should talk to Vlad Dan H: experiments with machine code snippets and intrinsics === Timing of MVT EA: after JVMLS - (sigh) - need to sync up on dates === Remi joined :-) MVT issues: 1) representation of __Value root type of all value types should it be boxed? Fred: No - can NOT box - there is no VCC associated with it Remi: how do we get from __Value to actual type? Today - there is no way to do this This is very temporary - longer term expect a new "mode" of Object, "QObject" Can't use for fields may need an unsafe hook to load a value from an instance My notes say that __Value allows reflection on it. (ed. note - is that accurate? Do you mean ValueType reflection or older reflection? We are planning to disallow older reflection for MVT for value ASM patch progress: 1) openjdk w/ASM re-align with module opcodes 2) do next patch -- almost ready to submit first patch (!) corrections welcome, Karen
