RFR(S): 8043125: compiler/types/correctness/CorrectnessTest.java: assert(layout->tag() == DataLayout::speculative_trap_data_tag) failed: wrong type
vladimir.kozlov at oracle.com
Sat Aug 2 18:25:08 UTC 2014
On 8/1/14 10:00 PM, Roland Westrelin wrote:
> Thanks for reviewing this, Vladimir.
>> Can you add set_speculative_traps_cleaned_up() setter method?
>> Can you also change suffix _cleaned_up to _modified or _updated?
>> Otherwise clear_*_cleaned_up sounds strange.
>> So safepoint can happen during translate_from() call. Right? Please say
>> it in your comment?
> I made the changes you suggested above:
> Regarding this:
>> The comment said that new traps can be added but I don't see the flag
>> state change for such case.
> A trap is added during deoptimization. When a trap is added the
> extra_data_lock is acquired (in MethodData::bci_to_extra_data()). In
> ciMethodData::load_extra_data_helper(), once the extra_data_lock is
> acquired, we are guaranteed that no new traps can be added so there's no
> need to flag the state change for new traps. New traps may have been
> added before the extra_data_lock is acquired. I updated the comment to
> make this clearer.
>> On 7/30/14 1:43 PM, Roland Westrelin wrote:
>>> Speculative traps recorded in a MethodData can be removed at a
>>> safepoint. During a compilation, as an MethoData is copied and
>>> translated by a compiler thread to build a ciMethodData, a safepoint can
>>> occur as speculative traps are being copied, and speculative traps may
>>> be removed. I fixed this by adding a flag to the MDO that is set when
>>> speculative traps are removed. The code that copies the speculative
>>> traps to the ciMethodData, checks the flag as it iterates over the traps
>>> and if it detects a change, it starts the copy over. I took this
>>> opportunity to clean the code a bit: args_data_limit() points right
>>> after the last ArgInfoData entry while extra_data_limit() points after
>>> the parameters profiling area.
More information about the hotspot-compiler-dev