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