Condensing bootstraps

[Dan Heidinga]

On Fri, Aug 4, 2023 at 12:07 PM Brian Goetz <brian.goetz at oracle.com> wrote:

>
> > 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.
>
> Indeed.  And, if such checks are not reliable, we might need to generate
> more defensive code (such as having serialization methods that throw.)
> This is yet another reason why ultimately, we have to expose this in the
> programming model -- there are just too many subtle differences between
> online and offline to either automate or to tell bootstrap authors
> "here's the rules you have to follow to be safe."
>
> > 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.
>
> So, this does mean that we probably need to pass something more to the
> offline bootstrap than just a class name; we need to pass some sort of
> (read-only?) condensation context, so it can get at the class hiearchy.
> But the more this looks like a condenser, the more we confront the "two
> different programming models" problem.
>

We already pass in one context object into the BSM - the Lookup object.
It's able to look up classes, methods, etc.  I haven't worked though the
implications of this but I'll throw it out anyway - would it make sense to
have a special kind of Lookup object for the offline mode that delegated
class lookups to the condensation context?  Do we need some kind of common
supertype between j.l.Class and ClassDesc that allows asking the kinds of
class relationship queries  (isAssignableFrom, getSuperclass,
getInterfaces, ...) in a way that can be run correctly in both modes?

What I'm trying to get at is what kind of code can we run in both online
and offline modes?  Offline mode can't produce j.l.Class, will have
challenges dealing with accessibility especially across classloader
boundaries, others?

More experiments are needed here to see how easy it is to write code that
is applicable in both modes.  Maybe you've already done them?


>
> > 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.
>
> I don't have an answer for this, but I have spent some time thinking
> about it.  The intuition is that classpath analysis is expensive and so
> we will want to cache it so it can be shared across condensation
> activities.  But of course, then we need cache invalidation and
> regeneration.  Which led me to think about the extent to which this
> information really needed to be shared at "arms length" (i.e., through
> an opaque chain of condensers.)  Which further led me to the idea to
> restructure the condensers chain so the sharing didn't cross a boundary;
> i.e., write a condenser that (a) does the analysis, and then (b)
> delegates to multiple condensers sharing that analysis. THen they can
> coordinate "within the boundary" which is easier than coordinating
> across a boundary.
>
> That neatly turns the problem around and makes the creation / update of
the hierarchy a private problem between cooperating condensers.  It may
eventually make sense to provide an implementation of the hierarchy builder
in the platform, but this approach nicely sidesteps the consistency problem.

--Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230804/439ce1cf/attachment.htm>