RFR: Split out ContinuationEntry and ContinuationWrapper classes

[Coleen Phillimore]

On Thu, 14 Apr 2022 07:31:14 GMT, Ron Pressler <rpressler at openjdk.org> wrote:

>> Moved ContinuationEntry and ContinuationWrapper to their own files.
>> There's a bit of inconsistency because 3 ContinuationEntry functions are in ContinuationHelper_cpu.inline.hpp - maybe we should have continuationEntry_cpu.inline.hpp files for just the three.
>> I'd like to change the name ContinuationEntry to ContinuationAnchor or ContinuationFrameAnchor but want to study how that would look a bit more first.
>> Tested with other platforms and testing with loom-tier1 as sanity.
>
> src/hotspot/share/runtime/continuationWrapper.cpp line 50:
> 
>> 48:   disallow_safepoint();
>> 49:   read();
>> 50: }
> 
> This constructor should go in the .inline file.

I thought I should move these back.

> src/hotspot/share/runtime/continuationWrapper.inline.hpp line 51:
> 
>> 49: 
>> 50:   short _e_size;
>> 51:   short _e_num_interpreted_frames;
> 
> The two JFR fields can be moved out of ContinuationWrapper altogether and put into a FreezeThawBase class in continuationFreezeThaw.cpp, where they can be guarded by `#if CONT_JFR`.

I don't see the point of having this mess for two variable initializations.

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

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