Toward Condensers

[Brian Goetz]

I'll answer your questions with more questions.

Part of your question depends on: is applying an update to a model 
(producing a new model) expensive enough that it is better to let an 
updater also act as a model-view of sorts, or should you just apply the 
update whenever you want to make changes visible to later operations, 
and move on?  Secondarily, it raises the question about what the natural 
granularity of updates is: should a condenser batch all its updates into 
a single updater, or should it generate finer-grained updates?

As you point out, you have choices of how to write the condenser -- 
incrementally or batched.  Your initial example is incremental, 
searching for classes (B) with lambdas, and rewriting both that class 
and the nest host (A and B) together.  You then raise the possibility of 
accumulating a data structure of classes with lambdas to be rewritten, 
and doing it all at once.   This question of how to approach classfile 
transformation is essentially the same question as how to approach 
updating the application model, just moved around a bit.

My working assumption is that applying an update to a model will 
eventually be cheap enough that either option 2 or option 3 will always 
be preferable to option 1.  Option 1 involves a lot of "do the same 
thing two ways", which means more code, more surface, more confusion, 
and more chance for things to get out of sync.

To your question about classpath keys / module keys, the data model says 
these are singletons (the double circles.)  In the current (mostly 
mechanical) mapping of data model to API, for each attribute of these 
singleton keys, we generate a Stream-bearing method to iterate the 
attribute values (e.g., modules() and classPath()).  The actual 
ClassPathKey, being a singleton, is completely uninteresting (its an 
empty record) so it didn't get a representation in the API. (You might 
reasonably characterize this as premature API optimization, and that's a 
fair discussion.)


On 8/2/2023 10:36 AM, Dan Heidinga wrote:
> 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/06e5c847/attachment.htm>