RFR (S): 8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION
Vladimir Kozlov
vladimir.kozlov at oracle.com
Tue Nov 5 12:10:55 PST 2013
Looks good.
Thanks,
Vladimir
On 11/5/13 12:01 PM, Mikael Vidstedt wrote:
>
> Then there's the small matter of actually pasting in the link:
>
> http://cr.openjdk.java.net/~mikael/webrevs/8026775/webrev.02/webrev/
>
> Cheers,
> Mikael
>
> On 2013-11-05 11:51, Mikael Vidstedt wrote:
>>
>> John - that is a very good suggestion indeed, I took the liberty to
>> copy your exact wording.
>>
>>
>> All,
>>
>> I also added the closest I have gotten to a reproducer. Unfortunately
>> it is not completely reliable, in that it does not always reproduce
>> the bug, but I got it to the point where from empirical results it
>> tickles the bug some 80% of the cases (at least on my machine).
>>
>> Please review the updated comments and the added test!
>>
>> Thanks,
>> Mikael
>>
>> On 2013-11-04 11:58, John Rose wrote:
>>> + // Skip the first one because that was already touched in the above
>>> + // loop - the post decrement of temp means it's now a page below the
>>> + // last touch
>>>
>>> The comments should say 'tmp' not 'temp'. Also, the phrases 'first
>>> one' and 'it's now a page below' are hard to understand, and (to me)
>>> slightly misleading.
>>>
>>> Suggest:
>>> + // At this point, (tmp-0) is the last address touched, so don't
>>> touch it again.
>>> + // (It was touched as (tmp-pagesize) but then tmp was
>>> post-decremented.)
>>> + // Skip this address by starting at i=1, and touch a few more
>>> pages below.
>>> + // N.B. It is important to touch all the down to and including
>>> i=StackShadowPages.
>>>
>>> — John
>>
>
More information about the hotspot-compiler-dev
mailing list