RFR: 8367531: Template Framework: use scopes and tokens instead of misbehaving immediate-return-queries [v29]

[Christian Hagedorn]

On Wed, 12 Nov 2025 15:42:55 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> I got some feedback from users of the Template Framework, especially @galderz . And personally, I already was slightly unsatisfied by some of the issues described below, but did not expect it to be as bad as it is.
>> 
>> So I'm sorry, but I think we need to do a significant re-design. It is now still early enough, and only trivial changes are required for the "real" uses of the framework. Only the framework internal tests require significant changes.
>> 
>> Many thanks to @galderz for trying out the framework, and reporting the issues. And thanks to @chhagedorn for spending a few hours in an offline meeting discussing the issue.
>> 
>> **Major issue with Template Framework: lambda vs token order**
>> 
>> The template rendering involves some state, such as keeping track of hashtag replacements, names and fuel cost.
>> Some methods have side-effects (`addDataName`, `let`, ...) and others are simple queries (`sample`, ...).
>> Sadly, the first version of the template framework was not very consistent, and created tokens (deferred evaluation, during token evaluation) for some, and for others it queried the state and returned the result immediately (during lambda execution). One nasty consequence is that an immediately returning query can "float" above a state affecting token. For example, `addDataName` generated a token (so that we know if it is to be added for the template frame or a hook anchoring frame), but answered sampling queries immediately (because that means we can use the returned value immediately and make decisions based on it immediately, which is nice). Looking at the example below, this had the confusing result that `addDataName` only generates a token at first, then `sample` does not have that name available yet, and only later during token evaluation is the name actually added.
>> 
>> var testTemplate = Template.make(() -> body(
>>     ...
>>     addDataName("name", someType, MUTABLE),
>>     let("name", dataNames(MUTABLE).exactOf(someType).sample().name()),
>>     ...
>> ));
>> 
>> 
>> **Two possible solutions: all-in on lambda execution or all-in on tokens**
>> 
>> First, I thought I want to go all-in on lambda execution, and have everything have immediate effect and return results immediately. This would have the nice effect that the user feels like they are directly in control of the execution order. But I did not find a good way without exposing too many internals to the user, or getting rid of the nice "token lists" we currently have inside Templates (the...
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   inflate abreviations to full names

Thanks for the updates, some last nits :-)

test/hotspot/jtreg/compiler/lib/template_framework/CodeFrame.java line 99:

> 97:  *   t1 c1  t2 c2b ... t3 c3 <-- TemplateFrame nesting ---t4     c4
> 98:  *   t1 c1  t2 c2b ... t3 c3     with hashtag             t4     c4                            // t: Concerns Template Frame
> 99:  *   t1 c1  t2 c2b ... t3 c3     and setFuelCost          t4     c4                            // c: Concerns Code Frame

My mistake :-)


Suggestion:

 *   t1 c1  t2 c2b ... t3 c3     with hashtag             t4     c4                            // t: Concerns TemplateFrame
 *   t1 c1  t2 c2b ... t3 c3     and setFuelCost          t4     c4                            // c: Concerns CodeFrame

test/hotspot/jtreg/compiler/lib/template_framework/TemplateFrame.java line 53:

> 51:  * has such a set of hashtag replacements, and implicitly provides access to the
> 52:  * hashtag replacements of the outer {@link TemplateFrame}s, up to the outermost
> 53:  * of the current {@link Template}. If a hashtag replacemnt is added in a scope,

Suggestion:

 * of the current {@link Template}. If a hashtag replacement is added in a scope,

test/hotspot/jtreg/compiler/lib/template_framework/TemplateFrame.java line 54:

> 52:  * hashtag replacements of the outer {@link TemplateFrame}s, up to the outermost
> 53:  * of the current {@link Template}. If a hashtag replacemnt is added in a scope,
> 54:  * we have to find traverse to outer scopes until we find one that is not transparent

Suggestion:

 * we have to traverse to outer scopes until we find one that is not transparent

test/hotspot/jtreg/compiler/lib/template_framework/TemplateFrame.java line 65:

> 63:  * on how deeply nested the code is at a given point, correlating to the runtime that
> 64:  * would be spent if the code was executed. The idea is that once the fuel is depleated,
> 65:  * we do not want to nest more deaply, so that there is a reasonable chance that the

Suggestion:

 * we do not want to nest more deeply, so that there is a reasonable chance that the

-------------

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27255#pullrequestreview-3458081151
PR Review Comment: https://git.openjdk.org/jdk/pull/27255#discussion_r2522077796
PR Review Comment: https://git.openjdk.org/jdk/pull/27255#discussion_r2522066438
PR Review Comment: https://git.openjdk.org/jdk/pull/27255#discussion_r2522067532
PR Review Comment: https://git.openjdk.org/jdk/pull/27255#discussion_r2522060969