implicit constructor translation?

[John Rose]

On 1 Jun 2023, at 12:34, Brian Goetz wrote:

> On 6/1/2023 2:32 PM, Dan Heidinga wrote:
>>
>>
>> On Thu, Jun 1, 2023 at 1:59 PM Brian Goetz <brian.goetz at oracle.com> 
>> wrote:
>>
>>     I think that there should be an explicit (and not synthetic)
>>     method_info for the implicit constructor, with the obvious Code
>>     attribute (`defaultvalue` / `areturn`.)
>>
>>
>> I'm slightly concerned about having a Code attribute for the implicit 
>> constructor as it allows agents (ClassFile load hook & redefinition) 
>> to modify the bytecodes to be inconsistent with the VM's behaviour 
>> given the VM won't actually call the implicit constructor.
>>
>> Telling users it's "as if" the VM called the implicit ctor and then 
>> having the reflective behaviour be different after retransformation 
>> is slightly uncomfortable.
>
> I'm fine if the expansion of the constructor body happens at runtime 
> rather than compile time; my suggestion was mostly "this is super-easy 
> in the static compiler, why make more work for the JVM." But, if 
> you're signing up for that work, I won't stop you....

I haven’t signed up the JVM for that work!  It seems like busy-work to 
me.  JVM code which implements some busy-work requirement costs money 
for no benefit, and its (inevitable) bug tail risks increased attack 
surfaces.

I’m assuming (a) the `aconst_default` bytecode is not API (it’s 
private) and therefore that (b) any materialization of a default value 
will go through either the class’s API (real `new C()`) or else via 
some reflective API point (`C.class.defaultValue()`).  Maybe something 
very simple like:

```
C defaultValue() {
   // if the next line throws an exception, it goes to the client
   var a1 = Array.newInstance(asNonNullable(), 1);
   // at this point we know C has a default value
   return (C ) Array.get(a1, 0);
   //OR?? return this.newInstance();
}
```

Regarding the problem of agents, I’d say either we don’t care what a 
buggy agent does, or else we can might add an implementation restriction 
that refuses to allow a buggy agent to load an implicit constructor with 
a bad body.

Agents can modify all sorts of JDK internals.  (Also non-javac-spun 
classfiles explore all sorts of odd states.)  We can’t play 
whack-a-mole trying to prevent all kinds of agent misbehavior.  That 
would just end up creating an endless parade of costs and bugs.

And I don’t want to add a verification rule; the costs of tweaking the 
verifier far outweigh the benefits.  Let’s give some basic trust our 
classfile generators and agents.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20230606/fc24ead3/attachment.htm>