JEP update: Value Objects

[Dan Heidinga]

On Thu, Dec 2, 2021 at 10:05 AM Dan Smith <daniel.smith at oracle.com> wrote:
>
> On Dec 2, 2021, at 7:08 AM, Dan Heidinga <heidinga at redhat.com> wrote:
>
> When converting back from our internal form to a classfile for the
> JVMTI RetransformClasses agents, I need to either filter the interface
> out if we injected it or not if it was already there.  JVMTI's
> GetImplementedInterfaces call has a similar issue with being
> consistent - and that's really the same issue as reflection.
>
> There's a lot of small places that can easily become inconsistent -
> and therefore a lot of places that need to be checked - to hide
> injected interfaces.  The easiest solution to that is to avoid
> injecting interfaces in cases where javac can do it for us so the VM
> has a consistent view.
>
>
> I think you may be envisioning extra complexity that isn't needed here. The plan of record is that we *won't* hide injected interfaces.

+1.  I'm 100% on board with this approach.  It cleans up a lot of the
potential corner cases.

> Our hope is that the implicit/explicit distinction is meaningless—that turning implicit into explicit via JVMTI would be a 100% equivalent change. I don't know JVMTI well, so I'm not sure if there's some reason to think that wouldn't be acceptable...

JVMTI's "GetImplementedInterfaces" spec will need some adaptation as
it currently states "Return the direct super-interfaces of this class.
For a class, this function returns the interfaces declared in its
implements clause."

The ClassFileLoadHook (CFLH) runs either with the original bytecodes
as passed to the VM (the first time) or with "morally equivalent"
bytecodes recreated by the VM from its internal classfile formats.
The first time through the process the agent may see a value class
that doesn't have the VO interface directly listed while after a call
to {retransform,redefine}Classes, the VO interface may be directly
listed.  The same issues apply to the IO interface with legacy
classfiles so with some minor spec updates, we can paper over that.

Those are the only two places: GetImplementedInterfaces & CFLH and
related redefine/retransform functions, I can find in the JVMTI spec
that would be affected.  Some minor spec updates should be able to
address both to ensure an inconsistency in the observed behaviour is
treated as valid.

--Dan