Condensing bootstraps

[Dan Heidinga]

I like this approach as it allows online and offline BSMs to share an
implementation while still leaving the door open to separate
implementations where necessary.  BSM authors will be on the hook for some
additional effort as there are things that are trivial to check at runtime
given the current apis on Class that are harder to check offline.

One of example of this is the "is accidentally Serializable" check in the
LambdaMetaFactory which can be trivially do with:
    Serializable.class.isAssignableFrom(interfaceClass);
in online mode but requires an offline model of the class hierarchy to
check.

Validating class relationships - often done in indy BSMS - raises the issue
of needing an offline view of the class hierarchy and some way to keep it
up to date with changes that condenser may make to the model.  Adding or
removing classes, changing the set of implemented interfaces, even
reordering the classpath may require expensive rebuilds of the class
hierarchy view.

Many years ago I worked on porting EnvySmalltalk into a FileBasedSmalltalk
for use with an Eclipse UI.  To make that work, we had to maintain an index
of class relationships and use the Eclipse Listener-events to keep the
index up to date.  If the index became inconsistent for any reason, we
dropped it and rebuilt it completely.  The point being that having Listener
mode allowed us to share the cost of updates across all consumers of the
index while keeping in sync with changes.  It may be helpful to support a
similar Listener event model on the ModelUpdater so plugins can share
metamodels (ie: class hierarchy) without needing each condenser to create
the same metamodel themselves.

> A condy can appear as the operand of an LDC, in the static argument list
of an indy or condy bootstrap, or in any attribute that uses constant pool
indexes.

My understanding is that condy is only usable where loadable constants can
be used, which is LDC or in the static argument list of a BSM.  Constant
pool indexes are static data in the classfile and VM implementations are
free to reorder / rewrite / replace them in their runtime representations
of classes which would make it very hard to have condy produce constant
pool indexes.  If condy could produce new CP entries, we'd have some very
complicated verification and resolution rules to handle the cp mapping.  It
just wouldn't be worth it.

I think the same solution is applicable for condy as for indy.  There's no
special case here.

--Dan

On Wed, Aug 2, 2023 at 1:38 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> I've spent some time thinking about how to approach condensing `indy`
> sites.  My conclusion is that the "obvious" approaches are not really
> optimal, so I've sketched out a path to bringing the solution further
> into the programming model here:
>
> https://openjdk.org/projects/leyden/notes/04-condensing-bootstraps
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230804/c07498bf/attachment.htm>