RFR(s): 8222640: Remove deopt suspend

[Robbin Ehn]

Hi Dan, thanks for digging!

Yes, I have already forward the mail to compiler, added here also.

Thanks, Robbin

On 2019-04-17 15:46, Daniel D. Daugherty wrote:
> On 4/17/19 4:35 AM, Robbin Ehn wrote:
>> Hi all, please consider this change.
>>
>> The code for deopt suspend is no longer needed since today the register window
>> is always flushed when this code executes. Exactly when this code was needed is not clear, entered via duke changeset 
>> 1. I did not dig since we no longer have such use case.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rehn/8222640/webrev/
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8222640
>>
>> Passes t1-5.
>>
>> Thanks, Robbin
> 
> Since this code was added by the Compiler team, I think you're going
> to want at least one Compiler team member to chime in on this review...
> 
> 
> I was going to add a historical comment to your bug, but JBS appears to
> be down at the moment... This code was added by this delta:
> 
> $ sp -r1.795.1.1 src/share/vm/runtime/thread.cpp
> src/share/vm/runtime/SCCS/s.thread.cpp:
> 
> D 1.795.1.1 06/12/07 10:06:52 sgoldman 2086 2084 00031/00010/04023
> MRs:
> COMMENTS:
> 6463133 - patchless deopt. Support specialized deopt suspend for register window
> based machines. Pass registerMap to revoke_bias to prevent redundant stack
> walks.  frames now cache the codeBlob.
> 
> 
> Looks like 6463133 was not a bug that I was tracking way back then
> so I don't have an email folder for it. I did find Steve Goldman's
> push message for it, but the fix for 6463133 is included with four
> other bug fixes:
> 
> ---------------------------------------------------------
> 
> Job ID:                 20061207101238.sgoldman.6463133_deopt-M
> Original workspace:     gretch:/disk2/ws/6463133_deopt-M
> Submitter:              sgoldman
> Archived data: /net/prt-data.east/archives/main/c2_baseline/2006/20061207101238.sgoldman.6463133_deopt-M/
> Webrev: 
> http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2006/20061207101238.sgoldman.6463133_deopt-M/workspace/webrevs/webrev-2006.12.07/index.html 
> 
> 
> Fixed 6463133: Deoptimization should not use code patching
> Fixed 6490483: Java support for pstack broken
> Fixed 6490489: java pstack support for server on x86 corrupts stack frame info
> Fixed 6490492: java support for pstack rarely gets server compiled frames correct.
> Fixed 6500866: jvm crash running forte stress kit.
> 
> This converts deoptimization to no longer do patching of code
> and now only patches return address. This made a rather large
> change to the frame object so that now a frame always carries
> along the codeBlob it refers to if it in fact does refer to
> a codeBlob. This removes lots of redundant CodeCache::find_blob
> calls. The testing of this fix which obviously changes the way
> frames look on the stack discovered that both SA and pstack support
> have been broken. pstack support has been been broken for years.
> As part of the SA changes I found that the fix for:
> 
> 6252656: Putative invariant for TLABS _start+_size==_end+alignment_reserve() not being maintained
> 
> didn't properly update SA and I've added that fix.
> 
> There is a discussion of patchless deopt here
> 
> http://j2se.sfbay/web/bin/view/HotspotCompilers/PatchlessDeopt
> 
> which is currently (Dec. 7, 2006) out of date but which I will clean up.
> 
> One other notable change with this putback is that there is no longer a separate
> exception handler for each codeblob. Now the exception handler (and the new
> deopt handler) are stored in the stub (read uncommon code) area.
> 
> 
> Reviewed by: Tom
> 
> Fix verified (y/n): yes
> 
> Verification testing:
> 
>      PRT with various stress options. NSK and JDI tests with and without stress
>      options. Dan's forte stress tests on sparc/x86/amd64. Lots of various hand
>      testing of SA (in addition to sasanity) pstack, and dtrace.
> [end sgoldman Thu Dec  7 13:56:55 2006 EDT]
> 
> sgoldman Mon Dec 11 15:28:48 2006 PDT
> -------------------------------------
> 
> 
> Since this is an integration push from c2_baseline -> main/baseline, I do
> not have the list of files modified. I would have to find the c2_baseline
> TeamWare workspace if it still exists. However, I'm not sure it would help
> much since 6463133 is combined with 4 other fixes...
> 
> I did a search for all of the files that mention 6463133 in their SCCS
> history and that list is 83 files long. Ouch. I've attached that list to
> this email.
> 
> Dan