> Ok. Let me know what you think now after a bit more explanation.
I'm good with it. Thumbs up!
Dan
On 10/21/16 1:13 PM, Chris Plummer wrote:
Hi Dan,
Thanks for the review. Comments inline below:
On 10/21/16 7:59 AM, Daniel D. Daugherty wrote:
On 10/20/16 2:28 PM, Chris Plummer wrote:
Hello,
Please review the following:
http://cr.openjdk.java.net/~cjplummer/8166679/webrev.00/webrev.hotspot/
src/cpu/aarch64/vm/frame_aarch64.cpp
So we're in a "if (StubRoutines::returns_to_call_stub()" block
and the assumption was that a frame that returns to a call stub
must be an entry frame. Hence the use of is_entry_frame_valid().
However, your investigation revealed that you can be in an
interpreter frame that returns to a call stub here. That sounds
both familiar and right :-)
L209: bool jcw_safe = (jcw < thread->stack_base()) && ( jcw
> (address)sender.fp());
nit: please remove extra blank here: "( jcw"
Ok.
I like the new JavaCallWrapper sanity check. I never thought of
that when I worked on AsyncGetCallTrace().
src/cpu/sparc/vm/frame_sparc.cpp
old L281: if (sender.is_entry_frame()) {
old L282: return sender.is_entry_frame_valid(thread);
old L283: }
I don't understand this one. Why isn't is_entry_frame_valid()
correct here? You are in a "if (sender.is_entry_frame())" block.
I starred at this one a bit too, since the code is not quite the same
as x86 and aarch64. I'm not 100% sure I got it right, so I opted to
just change it to what used to be there, especially since 8159284
never turned up on sparc. I did try to go down the path of making sure
that 8166679 (this CR I'm fixing) does occur on Solaris-sparc, but
getting Dev Studio installed on a Solaris-sparc machine was proving
difficult. Maybe I should take another stab at that.
As for the similarities and differences between the sparc code an x86,
for x86 before my changes we had:
if (StubRoutines::returns_to_call_stub(sender_pc)) {
...
frame sender(sender_sp, sender_unextended_sp, saved_fp,
sender_pc);
return sender.is_entry_frame_valid(thread);
}
And for sparc:
frame sender(_SENDER_SP, younger_sp, adjusted_stack);
if (sender.is_entry_frame()) {
return sender.is_entry_frame_valid(thread);
}
So for x86 we are only adding the sender.is_entry_frame_valid() check
if the "current frame" returns to a stub, but for sparc we are doing
the check if the "sender frame" is an entry frame. I don't know the
reason for this difference. Aren't stubs entry frames? If yes, it seem
that having the check done in this way would cause this CR on sparc
just like it does on sparc.
I can see wanting to add the JavaCallWrapper sanity check as
an additional check. If you do that:
L286 bool jcw_safe = (jcw <= thread->stack_base()) && ( jcw
> sender_fp);
nit: please remove extra blank here: "( jcw"
Ok.
src/cpu/x86/vm/frame_x86.cpp
Again we're in a if (StubRoutines::returns_to_call_stub()" block
so I see why is_entry_frame_valid() is not the right call.
L208: bool jcw_safe = (jcw < thread->stack_base()) && ( jcw
> (address)sender.fp());
nit: please remove extra blank here: "( jcw"
Ok.
OK so I understand the AARCH64 and X86 changes. I don't quite
understand the SPARC change... but I can be convinced otherwise.
Ok. Let me know what you think now after a bit more explanation. I can
put some more effort into trying out the test case on sprarc if needed.
thanks,
Chris
If you fix the nits, I don't need to see a new webrev.
Dan
https://bugs.openjdk.java.net/browse/JDK-8166679
The fix is to partially undo the changes for JDK-8159284. There are
two places where the fix for JDK-8159284 added an extra check of the
validity of the entry frame, but really only the first one is
appropriate since for the second one we are not in an entry frame.
More details can be found near the end of the bug comments.
Note I did a straight patch of the old version of the code. It could
probably use some formatting and comment cleanup. I decided not to
clean it up to make it easy to compare the current code with the
original. I'll clean it up if you feel it would be best to.
Tested by running KitchenSink more times than I can count, since
that's where JDK-8159284 turned up. However, that's not proving much
since I could not reproduce JDK-8159284 even without its fix in
place (it also couldn't be reproduced at the time JDK-8159284 was
was being investigated and fixed). For this reason I can't be 100%
sure that JDK-8159284 is not being re-introduced with my changes.
Also tested by running a very large set of tests trough RBT, close
to what we do for PIT testing, minus product builds and a few tests
that take a long time to run.
Lastly, I also tested with the test case in the CR to make sure it
now passes. Unforgettably it's not possible to add the test case as
a jtreg test since it requires the installation of the Oracle Studio
tools.
thanks,
Chris
