Another question about JEP 270: Reserved Stack Areas for Critical Sections

[Frederic Parain]

Thank you, I'll add this fix.

Fred

On 01/09/2017 12:23 PM, Andrew Haley wrote:
> On 09/01/17 15:31, Frederic Parain wrote:
>> Hi Andrew,
>>
>> I re-read this code a few days ago and I had the same question.
>> I believe it is a useless left over.
>> The throw_delayed_StackOverflowError entry has no additional argument,
>> and because it unconditionally starts the propagation of an exception,
>> the frame is destroyed and nobody can use this value on the stack.
>> I think it is safe to remove but I'll run some tests to double check.
>
> While you're looking at that code, you might want to do this:
>
> diff --git a/src/share/vm/opto/compile.cpp b/src/share/vm/opto/compile.cpp
> --- a/src/share/vm/opto/compile.cpp
> +++ b/src/share/vm/opto/compile.cpp
> @@ -992,7 +992,8 @@
>      _print_inlining_output(NULL),
>      _allowed_reasons(0),
>      _interpreter_frame_size(0),
> -    _max_node_limit(MaxNodeLimit) {
> +    _max_node_limit(MaxNodeLimit),
> +    _has_reserved_stack_access(false) {
>    C = this;
>
>    TraceTime t1(NULL, &_t_totalCompilation, CITime, false);
>
> As it stands, every opto runtime call is compiled with reserved
> stack access.
>
> Andrew.
>