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

Christian Hagedorn chagedorn at openjdk.org
Thu Nov 13 07:54:33 UTC 2025


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

>> test/hotspot/jtreg/compiler/lib/template_framework/StructuralName.java line 289:
>> 
>>> 287:         }
>>> 288:     }
>>> 289: }
>> 
>> Feels like we have a lot of duplication in `DataName` and `StructuralName`. But I'm not sure if/how we could share it somehow. Anyhow, not something for today.
>
> Maybe it could be somehow smartly collapsed. Maybe using some smart way with Generics. But I could not find a good solution yet. Right, it could be tried in a later RFE.

Me neither, it's just a feeling that it is possible, maybe with Generics or some reusable common class. Anyway, can be tackled later.

>> test/hotspot/jtreg/compiler/lib/template_framework/TemplateFrame.java line 55:
>> 
>>> 53:  * of the current {@link Template}. Inner scopes of a {@link Template} have access to
>>> 54:  * the outer scope hashtag replacements, and any hashtag replacement defined inside an
>>> 55:  * inner scope is local and disappears once we leave the scope.
>> 
>> We could explicitly mention here that we do not mean inner scopes that are templates themselves?
>> Suggestion:
>> 
>>  * of the current {@link Template}. Inner scopes of a {@link Template}, that are not
>>  * templates themselves, have access to the outer scope hashtag replacements, and any 
>>  * hashtag replacement defined inside an inner scope is local and disappears once we 
>>  * leave the scope.
>
> I'm not sure this is better:
> `Inner scopes of a {@link Template}, that are not templates themselves,`
>  Because they are only scopes of this template if they are not scopes of another template 😆 
> 
> I now wrote this, and hope it is a bit more helpful:
> 
>    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
> ~  55  * for hashtags (at most it is the frame of the Template), and insert it there.
> +  56  * The hashtag replacent is local to that frame, and accessible for any frames nested
> +  57  * inside it, but not inside other Templates. The hashtag replacement disappears once
> +  58  * the corresponding scope is exited, i.e. the frame removed.

That's better, good!

>> test/hotspot/jtreg/compiler/lib/template_framework/TemplateFrame.java line 60:
>> 
>>> 58:  * The {@link #parent} relationship provides a trace for the use chain of templates and
>>> 59:  * their inner scopes. The {@link #fuel} is reduced over this chain to give a heuristic
>>> 60:  * on how much time is spent on the code from the template corresponding to the frame,
>> 
>> "time" sounds misleading. What about: [...] on how many times we already nested the template corresponding to the frame recursively [...]?
>
> Hmm, well the idea is really to limit runtime once we run the generated code... But that correlates to the nesting depth and the iteration count of loops etc.
> 
> I now wrote this:
> 
>    61  * The {@link #parent} relationship provides a trace for the use chain of templates and
>    62  * their inner scopes. The {@link #fuel} is reduced over this chain to give a heuristic
> ~  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
> +  66  * execution of the generated code can terminate.

Great, that's much clearer 👍

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27255#discussion_r2522099442
PR Review Comment: https://git.openjdk.org/jdk/pull/27255#discussion_r2522070276
PR Review Comment: https://git.openjdk.org/jdk/pull/27255#discussion_r2522070468


More information about the hotspot-compiler-dev mailing list