VectorAPI reduction operation support for testing infrastructure

[Paul Sandoz]

> On Mar 30, 2018, at 9:12 AM, Halimi, Jean-Philippe <jean-philippe.halimi at intel.com> wrote:
> 
> Answers below.
> 

It’s hard to track and reply to your answers because they are quoted in such a manner they look like prior conversation.


> Thanks,
> 
> Jp
> 
> -----Original Message-----
> From: Paul Sandoz [mailto:paul.sandoz at oracle.com] 
> Sent: Friday, March 30, 2018 8:58 AM
> To: Halimi, Jean-Philippe <jean-philippe.halimi at intel.com>
> Cc: panama-dev at openjdk.java.net
> Subject: Re: VectorAPI reduction operation support for testing infrastructure
> 
> Hi,
> 
>> On Mar 30, 2018, at 7:11 AM, Halimi, Jean-Philippe <jean-philippe.halimi at intel.com> wrote:
>> 
>> Hi,
>> 
>> I have updated the webrev with a few more minor fixes and addressing your first comment. Paul, if you get the chance, please have a look at my answer to your second comment so that I can update it if necessary.
>> 
>> http://cr.openjdk.java.net/~jphalimi/webrev_reduction_testing_v1.3/webrev/ 
>> 
> 
> That looks good.
> 
> I did reply to your second comment in a prior email, but i don’t want to block progress. How about you push and i propose an additional patch, sometimes that is easier/quicker way to communicate an idea?
> 
>>> I didn't get that answer for some reason. My comment was:
>>> I understand that you want to factorize the reductions in one simple method. However it looks a bit complicated to do this way since you can't reach the vector from rOp. Or perhaps I missed something here?
>>> I haven't received an email from you since I sent out this email. Perhaps I missed it somewhere else?
>>> And of course, we can move forward as is and continue with a follow-up patch.
> 

Here it is:

  http://mail.openjdk.java.net/pipermail/panama-dev/2018-March/001406.html <http://mail.openjdk.java.net/pipermail/panama-dev/2018-March/001406.html>



> I see you added an optional to the run script to disable the intrinsics. We can also add this to the jtreg meta-data:
> 
>  @run testng/othervm $vectorteststype$
>  @run testng/othervm -XX:-UseVectorApiIntrinsics $vectorteststype$
> 
> (jtreg can accept additional JVM parameters on the command line, so i hesitated to add -XX:-TireredCompilation for now. See later.)
> 
>>> That is right. In fact I have been using the java flag with jtreg. There is one circumstance where I find the run-tests.sh script more useful. Namely, it is when a crash happens, I noticed that the crash trace files get removed for some reason (those located in the JTwork folder). Have you experienced this issue before?
> 

Oh, i am not aware of that. Usually when a crash happens i run with the verbose option to get a script to execute again, so it may be i never checked.


> No need for another review if you add this.
> 
> Running with -Xcomp is also useful for stress testing, you might wanna consider adding that option to your run script at some point.
> 
> —
> 
> Separately, to consider later on, i think we need to remove the invocationCount parameter from @Test and embed such a loop in the tests themselves, with a configurable loop iteration value.
> 
>>> Can you elaborate on why you think this will make it better? Isn't there a way to configure the invocationCount as well?
> 

Possibly, but i don’t trust the testng looping :-), it also fills up the reporting of test results (e.g. what if we increase to 10,000 so C2 kicks in), further we can more easily separate out the array allocation and assertion from any such loop if we so wish to focus C2 on the bits that matter.

Paul.