RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64

[Igor Veresov]

Thanks, Vladimir!

igor

On Oct 16, 2013, at 9:23 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> Good.
> 
> Thanks,
> Vladimir
> 
> On 10/16/13 9:20 AM, Igor Veresov wrote:
>> On Oct 16, 2013, at 9:00 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> 
>>> Igor,
>>> 
>>> New verification code should be under #ifdef ASSERT instead of #ifndef PRODUCT.
>>> And the print codes "fusion has incorrect" with path dump should be under PrintOptimizeStringConcat flag as in other places.
>> 
>> Duh, thanks for noticing that!
>> 
>> Here's the updated webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.4/
>> 
>> igor
>> 
>>> 
>>> Otherwise it is good.
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>> On 10/16/13 7:18 AM, Igor Veresov wrote:
>>>> I've added some code to verify the control flow pattern between the constructor calls and initialize. The control flow should be essentially a straight line, except for simple diamonds of casts, and things like null and class checks with the false branch ending with uncommon trap. Ran through ctw and jtreg to verify.
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.3/
>>>> 
>>>> igor
>>>> 
>>>> On Oct 14, 2013, at 5:38 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
>>>> 
>>>>> 
>>>>> On Oct 14, 2013, at 2:39 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>>> 
>>>>>> You don't need 'if()':
>>>>>> 
>>>>>> +         if (mem->is_MergeMem()) {
>>>>>> +           while (mem->is_MergeMem()) {
>>>>>> 
>>>>> ok
>>>>> 
>>>>>> Typo "the have" ("it is"?):
>>>>>> 
>>>>>> +           // now let it fall though, and see if the have a projection
>>>>>> 
>>>>> yup
>>>>> 
>>>>>> I wish you had some asserts for constructors case. May be check in debug VM that controls from Initialize to contructor don't have other uses.
>>>>>> 
>>>>> 
>>>>> Well, this is already handled in the control flow analysis, but sure, I'll add some code. I'll come back with this tomorrow.
>>>>> 
>>>>> Thanks!
>>>>> igor
>>>>> 
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>> 
>>>>>> On 10/14/13 1:57 PM, Igor Veresov wrote:
>>>>>>> Hi guys,
>>>>>>> 
>>>>>>> I had to go back and think about the solution to clear up some doubts. While my original solution mostly worked, there is actually a more efficient way to do the analysis in polynomial time.
>>>>>>> Basically the implementation boils down to verifying that there are no side effects between the first constructor and all the following calls by following the bottom memory slices up until we find a know call. The presence of memory slices of different alias types between the calls also indicate the side effect. As for the case when side effects (calls or stores) happen after allocation and before the constructor call they always have a control dependency on initialization, and therefore will be caught by the existing control flow validation.
>>>>>>> 
>>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.2/
>>>>>>> 
>>>>>>> Testing: jtreg, CTW, the failing tests
>>>>>>> 
>>>>>>> igor
>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>>