4-th round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found
Daniel D. Daugherty
daniel.daugherty at oracle.com
Sat Jan 17 02:24:11 UTC 2015
So redefining the Unsafe class is now very expensive because
we have to visit the i-table and v-table of every class (and
Based on the bug report 'Unsafe::throw_illegal_access' is some
magical method that can appear in any i-table or v-table entry.
Maybe only as part of some default methods thing? That's not
clear to me so I'm just guessing...
Is there some way to limit this visit to classes where the
magical method can appear? Or can it really appear anywhere?
On 1/16/15 12:14 PM, serguei.spitsyn at oracle.com wrote:
> Dan, David H. or David C.,
> May I ask one of you to look at the webrev below?
> The issue itself is a little bit tricky, so it is not easy to review
> despite the small size.
> Does the webrev matches what we discussed with you?
> Do you give me a thumbs up?
> May I ask
> On 1/13/15 9:47 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the fix for:
>> Open webrevs:
>> The sun.misc.Unsafe:throwIllegalAccessError() method is used in
>> place of a default
>> interface method in the itable if a default method was not defined
>> in the interface.
>> In fact, it happens for two interfaces that purhaps are
>> This approach creates a problem when the class sun.misc.Unsafe is
>> The Method* pointer to the old (redefined) method in the itable
>> triggers an assert
>> (see the hs_err log in the bug report).
>> Coleen told me that a similar approach is going to be implemented
>> for some vtable entries.
>> Coleen, thanks for suggesting a better fix for this issue!
>> The fix is to replace the old Unsafe method in the itable/vtable
>> with the latest method version.
>> In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests
More information about the hotspot-dev