RFR(M): 8026253: New type profiling points: sparc support

[Roland Westrelin]

Thanks for reviewing this, Chris.

> src/share/vm/c1/c1_LIRGenerator.cpp:
> 
> !   ciKlass* exact = profile_type(md, 0, md->byte_offset_of_slot(data, ret->type_offset()),
> !   ciKlass* exact = profile_type(md, md->byte_offset_of_slot(data, ret->type_offset()), 0,
> 
> What is this change?

The 2nd argument to profile_type is the offset within the MDO of the ProfileData about to be updated. The 3rd argument is the offset within the ProfileData of the entry to update. So for parameters for instance, the 2nd argument is the offset within the MDO of the ParametersTypeData and the 3rd argument is then set to the offset within the ParametersTypeData of the argument we want to profile, for each argument. The 2nd argument is used to set up a register with a pointer that is used for subsequent updates by using addresses relative to that register.
Return value profiling is a special case because there’s only one profile to update so 2nd and 3rd arguments can be exchanged. I swapped them because otherwise the 3rd argument is an offset that doesn’t always fit in a single sparc load/store instruction. An extra instruction is always emitted but the code is simpler.

> src/cpu/sparc/vm/interp_masm_sparc.cpp:
> 
> +         // We're right after the type profile for the last
> +         // argument. tmp is the number of cell left in the
> +         // CallTypeData/VirtualCallTypeData to reach its end. Non null
> +         // if there's a return to profile.
> +         assert(ReturnTypeEntry::static_cell_count() < TypeStackSlotEntries::per_arg_count(), "can't move past ret type");
> +         sll(tmp1, exact_log2(DataLayout::cell_size), tmp1);
> +         add(ImethodDataPtr, tmp1, ImethodDataPtr);
> 
> I think “tmp” is referring to “tmp1” and “cell” should be plural, shouldn’t it?

Yes. Thanks.

> Some comments are missing the final “.”.

Will fix that.

> Also, I didn’t verify the machine instructions in detail but a quick scan didn’t bring up anything obviously wrong.  I guess you did some testing.

I sanity checked with a simple test program that expected profiling is collected. I also did the usual testing to check that nothing unexpected happens when this is on.

Roland.

> 
> Looks good.
> 
> On Jan 9, 2014, at 12:35 AM, Roland Westrelin <roland.westrelin at oracle.com> wrote:
> 
>> http://cr.openjdk.java.net/~roland/8026253/webrev.00/
>> 
>> The main difference with the x86 code is that on sparc, the current profile value is loaded, checked & updated and finally stored rather than checked & updated in place as is done on x86. As a consequence the code is somewhat simpler because concurrent updates to the profile are not possible.
>> 
>> Roland.
>