RFR(S): 8043125: compiler/types/correctness/CorrectnessTest.java: assert(layout->tag() == DataLayout::speculative_trap_data_tag) failed: wrong type

[Roland Westrelin]

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:

http://cr.openjdk.java.net/~roland/8043125/webrev.01/

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.

Roland.

>
> Thanks,
> Vladimir
>
> 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.
>>
>> http://cr.openjdk.java.net/~roland/8043125/webrev.00/
>>
>> Roland.
>>