RFR: Freeze functions [v3]

[Robbin Ehn]

On Wed, 20 Apr 2022 12:24:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Robbin Ehn has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 339:
> 
>> 337:   const bool _preempt; // used only on the slow path
>> 338:   const intptr_t * const _frame_sp;
>> 339: 
> 
> Is this the sp of the first frame on the stack that we are going to freeze?

Yes

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 509:
> 
>> 507:   } else {
>> 508:     stackChunkOop chunk = allocate_chunk(_cont_size + frame::metadata_words);
>> 509:     if (freeze_fast_new_chunk(chunk)) {
> 
> It seems odd that freeze_fast_existing_chunk() doesn't pass a chunk but freeze_fast_new_chunk does.  Should the allocate_chunk be inside of freeze_fast_new_chunk?

The chunk is picked up from tail. Yes I agree it's not the way I liked.
But want to ship smaller pieces, since merging is really rough.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 606:
> 
>> 604:     log_develop_trace(continuations)("Retrying slow. Barriers: %d", _barriers);
>> 605:     return false;
>> 606:   }
> 
> This variable _cont_size is really strange.  Above we add in argsize for total size that we need to freeze, but here we set max_size to cont_size.  We should go through and see what we add and subtract from cont_size in various places and see what size is what (and if it's easier to figure out what's correct).  After this patch.
> I assume that this patch is mostly code motion and doesn't change the values in places, which is good.

Yes

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

PR: https://git.openjdk.java.net/loom/pull/156