Valhalla EG 20200408

David Simms david.simms at oracle.com
Thu Apr 9 06:46:55 UTC 2020


Attendees: Remi, Simms, Fred, DanH, Tobi, Brian, John

  - Brian: So I do owe a write up specialization, coming soon
  - DanH: Can both .ref and .val classes use `withfield` ?
  - Brian so this relates to a discussion on field protection:
      - Is it just the class itself or nest ?
  - Remi: so records, do we need more accessibility
  - DanH: so value type records vs non-value type record, we don't want 
different rules
  - Brian: previously wanted lang features like `x with { y.z = 3 }`
      - ...but don't know what that is in bytecode
  - DanH: seem like we should start restrictive
      - Brian: yeah, like only construction of inline types
  - Brian: current translation:
      - inline type: Fields and Constructor (Static Factory)
      - ref type: Methods
  - Brian: Assume John leans towards access boundary of the nest
  - John: yes, simpler same set of rules for all
      - Otherwise nest need bridges and feels like a mess
      - Wouldn't like to see more complexity (we've made that mistake 
before)
      - EG ML: "access control for withfield bytecode, compared to 
putfield" [1]
  - Brian: Previous discussion `InlineObject` and `IdentityObject`
      - Do we need both ? Can we drop one ?
      - DanH: so didn't we want this for template specialization ?
      - Brian: identity might the one we care for...
          - EG ML: "IdentityObject and InlineObject" [2]
  - John: Amber record default methods...
      - ...ClassValue: EG ML "ClassValue performance model and 
Record::toString" [3]
      - DanH: will have to check with JIT folks
  - Brian: further questions on SoV ?
      - DanH: `instanceof` with Q-type, could be optimized
      - Fred: special case for `null`, then the name is resolved
      - John: can we look into changing that in the spec...
          - "null checks vs. class resolution, and translation strategy 
for casts"
          - EG ML "null checks vs. class resolution, and translation 
strategy for casts" [4]

References:
  - 
[https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2020-April/001261.html](https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2020-April/001261.html)
  - 
[https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2020-April/001258.html](https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2020-April/001258.html)
  - 
[https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2020-April/001260.html](https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2020-April/001260.html)
  - 
[https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2020-April/001259.html](https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2020-April/001259.html)




More information about the valhalla-spec-experts mailing list