Toward Condensers

[Dan Heidinga]

Is there a way to query the current value from a ModelUpdater?

The use case I'm thinking of is likely to be fairly common where updating
one class requires updates to another (ie: Nest attributes).  Take the
follow nest of classes and a condenser that pregenerates lambdas as an
example:

class A {
  NestMembers: [B, C]
}

class B {
   NestHost: A

   void foo() { Runnable r = () -> ....; }
}

class C {
   NestHost: A

   void bar() { Runnable r = () -> ....; }
}

When processing class B, a new class will be generated and it will be
necessary to update A's NestMembers to include the pregenerated class so
the constraint that the Host knows its members is maintained.  Similarly,
when processing class C, A's NestMembers will again need to be updated.

I think this becomes the following calls to the APIs:

public ApplicationModel condense(ApplicationModel model) {
  // NIT: Should this be ApplicationModel or Model?  Examples use
ApplicationModel but interface is named "Model"

  ModelUpdater updater = model.updater();

  // -----  process class B ------
  // update the nestHost's nestMembers
  ClassKey classK = getNestHostClassKey(?????);
  updater.addToContainer(classK,
      updateNestHost(model.classContents(classK)));  // First fetch of
classContents

  // -----  process class C ------
  // update the nestHost's nestMembers
  ClassKey classK = getNestHostClassKey(?????);
  updater.addToContainer(classK,
       updateNestHost(model.classContents(classK))); // Critical line:
where do I get classContents?

  return model.apply(updater);
}

The critical question is where do I get the classContents for the second
update to the classK?  The Model is immutable so the second query will get
the original bytes and lose the changes done by the first update.

Option 1: Query the ModelUpdater instead?  That would imply that
ModelUpdater extends Model which may be ugly to patch the Stream's to
return the updated values instead.

Option 2: Batch the updates and only apply them once?  That's what I do now
in the jlink plugin but it means carrying more state in the condenser.  It
keeps this as the users problem to manage state

Option 3: Generate a new Model after every transformation?

Model m = model;
{
   ModelUpdater mUpdater = m.updater();
  // Process class B
  m = m.apply(mUpdater);
}
{
   ModelUpdater mUpdater = m.updater();
  // Process class C
  m = m.apply(mUpdater);
}

All three options are workable but result in different API shapes.  Option
3 has some nice debugging properties in that it's always easy to see what
changed in each transformation and it may play well with structured logging
as discussed in the other thread.

An unrelated question: where does ClassPathKey() or ModulesKey() show up in
the model?  They aren't subtypes of ContainerKey which is where I expected
them to appear.  How do you see them being used?

Sorry for the deluge of questions / comments.  I'm excited to see the
progress here.

--Dan


On Mon, Jul 31, 2023 at 4:31 PM Mark Reinhold <mark.reinhold at oracle.com>
wrote:

> A few of us have been thinking about how condensers might work.  We now
> have a prototype design and implementation of a condenser API and tool.
>
> We’ve deliberately started small, focusing on principles of condenser
> operation and a minimal set of features sufficient for the simplest
> condensers, i.e., those that don’t require additional changes to the
> Platform Specification.
>
> Design note:
> https://openjdk.org/projects/leyden/notes/03-toward-condensers
>
> Summary:
>
>   We elaborate the concept of composable condensers to introduce a
>   simple, abstract, immutable, data-driven model of applications so that
>   condensers can be expressed as transformers of instances of the model.
>   The model is sufficient to express simple condensers; we include two
>   examples.
>
> This is just a starting point; we expect to evolve it considerably going
> forward.  We’ll publish the prototype code shortly after we return from
> the upcoming JVM Language Summit.
>
> - Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230802/8e46612f/attachment.htm>