Loading...

XML

Word

Printable

Type: Enhancement
Resolution: Fixed
Priority: P4
Fix Version/s: hs10
Affects Version/s: 6
Component/s: hotspot
Labels:
None

Subcomponent:
compiler
Resolved In Build:
b06
CPU:

generic
OS:

generic

Issue	Fix Version	Assignee	Priority	Status	Resolution	Resolved In Build
JDK-2176812	7	Erik Trimble	P3	Closed	Fixed	b06
JDK-2171816	6u4	Abhijit Saha	P3	Resolved	Fixed	b03

Deoptimization is susceptible to failure because it uses cross code patching. At the moment we know of no cpu's where this fails but we may well be running out of time. Newer Intel processors have an errata which isn't planned to be fixed that hints that we could fail.

We should use a deopt scheme that uses return address patching instead. This also allows us to go to single frame deopt. a capability we lost when lazy deopt was implemented.

backported by

JDK-2171816 Deoptimization should not use code patching

Resolved

JDK-2176812 Deoptimization should not use code patching

Closed

relates to

JDK-6511756 forte_is_valid_method() should call CollectedHeap::is_in_reserved() rather than is_in()

Closed

JDK-6670173 SA: jstack fails due to null sp on x86

Resolved

JDK-6507028 _suspend_flags are not atomically updated in all cases

Closed

JDK-6669441 Performance regression running javac in 6u4 using -server

Closed

JDK-6603919 Stackwalking crash on x86 -server with Sun Studio's collect -j on

Closed

(2 relates to)

Assignee:: Steve Goldman (Inactive)

Reporter:: Steve Goldman (Inactive)

Votes:: 0 Vote for this issue

Watchers:: 0 Start watching this issue

Created:: 2006-08-23 09:53

Updated:: 2010-04-02 15:29

Resolved:: 2007-01-17 13:11

Imported:: 17/Sep/12 12:24 AM

Indexed:: 19/Jul/12 5:53 PM

Details

Backports

Description

Attachments

Issue Links

Activity

People

Dates