Another question about JEP 270: Reserved Stack Areas for Critical Sections
Andrew Haley
aph at redhat.com
Mon Jan 9 17:23:25 UTC 2017
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.
More information about the hotspot-runtime-dev
mailing list