implicit constructor translation?

[Dan Heidinga]

On Tue, Jun 6, 2023 at 10:47 PM John Rose <john.r.rose at oracle.com> wrote:

> 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.
>

Definitely curious about the busy-work here as my mental model for this is
that it's a fairly cheap implementation akin to the code required to throw
AbstractMethodError.


> 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.
>

Agreed.  I'm not concerned about buggy agents but about user expectations
and avoiding an attractive nuisance.  By having bytecodes in the implicit
constructor, we encourage users to think they can modify its behaviour.
Again, user expectation matters.  Though these typically will be power
users so there's more leeway for technical explanations.

Detailing the way the implicit language level constructor generates both
the ImplciitCreation and the helper <vnew> method would be a great fit for
the (non-existent) translation guide.  I'm OK with spec'ing our way out by
saying the <vnew> generated for the implicit constructor is only a helper
but I don't know which spec we would put that info in.

--Dan


> 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-observers/attachments/20230613/e3098d77/attachment.htm>