Valhalla VM notes Wed Jun 6

[Karen Kinnear]

Accidentally sent this internally, incorporated Tobias’ corrections from last week:
> On Jun 12, 2018, at 6:01 PM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
> Attendees: Mandy, Frederic, Tobias, Harold, Karen, Roland joined (corrections welcome)
> 
> 1. Frederic - VTs attribute consistency
>   - throws ICCE at mismatch: fields: load time, local methods: preparation time
>   - also check against real - at constant pool resolution time - this will cover array creation, checkcast, etc.
> 
> was waiting for Srikanth’s updated bytecode APIs - so way to specify VTs attribute in the test
> (Srikanth sent an update after that)
> 
>    - also need consistency checks between caller/callee for method invocation and remote field reference
> 
> goal 1 correctness
> goal 2 avoid mismatches
> longterm picture: VBC migration - will not throw ICCE
> 
> 2. static fields:
> John wants value classes without circularity error
> Karen discussed at EG meeting - AI to do an improved writeup - Dan Smith pointed out some issues if the VTs attribute is incorrect,
> I need to walk-through the logic again. My AI.
> Note: will never actually flatten, but need semantics of can not be null
>   key: creating default value before class initialization - ensuring never exposed
>   (Karen investigating bug found when searching here - JVMTI returns jfieldID/jmethodID without class initialization, and passed
>    to JNI which assumes class has already been initialized before returning jfieldID/jmethodID - Dan D also thinks this is a bug -
>    trying to catch holes so instance of default value does not escape
> 
> (note: LW1: John agreed we could disallow this if we need to - i.e. keep current circularity checks if you try)
> 
> 3. verifier for container model: done - checks bytecodes, no nullability checks
>   (if we need to change to non-nullable types: 3-4 lines and some additional tests)
> 
> 4. interpreter: all set for LW1
> 
> 5. Classfileparser: all set for LW1
>   (if we need to remove ACC_FLATTENABLE from classfile - fallback - let classfileparser add the information so internal
> vm implementation unchanged after that)
> 
> 6. JIT:
> 
> Tobias: implementation is good for LW1
> calling convention not needed in 1st EA - we agreed - ok as optimization followup LW 1.1 or whatever
> 
> Roland: checked in intrinsics (bugs fixed since meeting)
>  1-2 intrinsics left:
>   hashcode/identityhashcode, (1 other maybe?)
> 
> 7. Library work:
> Discussion with Mandy:
>  prototyping hashcode using indy - waiting on Srikanth to generate compiler support
>  initial implementation is using reflection, working with Paul for MH combinators
>  model is to allow changing the algorithm in the library
>  algorithm: get all values from all fields
> 
> Ed Note: one possibility is to have C2 support hashcode intrinsic with default algorithm and use library if user overrides
> 
> Proposal from Mandy (correct me if this is inaccurate:)
> LW1: use library only, no C2 fallback hashcode intrinsic - expect this to be slow for LW1
> improve with LW 1.1 or whatever (e.g. with caching)
> 
> No other library work outstanding for prototype - Mandy wants to do another pass at Reflection, j.l.invoke for EA - but
> code and tests are there
> 
> 7. Work left for LW1:
> 1. enable JIT intrinsics for hashcode/equals for non-value types for performance - Roland
And other Object methods/bytecodes on value types - e.g. monitor enter: JDK-8204615 - Tobias working on
> 2. acmp from experimental tree - Mr Simms
> 3. JIT: aastore/aaload
> - potential future optimizations (replace de-opts by runtime calls) - not required for LW1
> 4. Mandy/Srikanth - hashcode/identityhash/equals
> 5. Frederic - update on VT consistency
> 
> 8. Testing and stability:
> Harold ran jck, jtreg without EnableValhalla - occasional small issues
> Harold offered to run with EnableValhalla (he sent email update
> Test with enableValhalla vs. not
> 
> 9. Longer-term:
> LW1: ship sooner - no value types as type parameters, no value-based-class migration
> 
> LW10: 1st preview
>   - support for erased generics
>      “working” means - e.g. pass in an array of Point and not get NPE when storing null, and not NPE when returning null and expecting Point
>   - language support - e.g. constructors
>   - preview quality: e.g. JNI, JVMTI, … - fully featured
>   - open question: are atomics required?
> 
> we would like to target JDK12 for LW10 - this may be a stretch goal - but we need to figure out what it will take
> 
> LW100: VBC migration (also requires handling nulls)
>     generic specialization for optimizations
>     primitives as value types
> 
> Between LW1 and LW10: may have performance optimization incremental EAs (periodically)
> 
> 10. JIT performance today relative to null handling:
>    null for value type dynamic argument: catch in i2c adaptor and jump to interpreter
>    null for value type return: deopt (do not throw away compiled code)
>    check null at checklists to a value type for scalarization within a method
>    array store: throws ASE/NPE
> 
> 11. Longer term proposals:
> Frederic is writing up a Container Model proposal - will send in email
> 
> thanks,
> Karen
> 
> 
> 
> 
> 
>