Changes to Bellsoft/Marvell method of developing intrinsics

[Andrew Haley]

On 1/23/19 5:27 PM, Derek White wrote:

> Because of this we will change how we develop patches for complex
> intrinsics. Before sending the code out for public review, we intend
> to:
> 
>   * Use an additional “red-team” developer to focus on finding the
> weak points in the code and develop tests that ensure code coverage
> testing, test case coverage, etc. This is in addition to the normal
> testing and test development that the initiating developer is
> expected to do.

>   * The “red-team” developer will also suggest changes for code
> clarity and code documentation, and will document the test strategy
> (what cases are tested, what tests cover what code, how to run
> tests).

>   * We will include all tests developed as part of the patch, even
> if some modes may not be practical to run regularly as jtreg tests
> (for example if some tests take excessive time). This will allow
> later enhancements or fixes to the intrinsic to go through at least
> as thorough testing as the original.

Thank you for that. I would like to add one thing: before doing
anything you should openly discuss whether a change should be made
at all. We need to know the potential gains, the maintenance costs, and
what the alternatives are.

For example, it may well be possible to write intrinsics in C++ with a
little vector code that will perform nearly as well as hand-carved
assembly language. These will be much cheaper to write, easier to
maintain, and more reliable, for all the usual reasons to do with
high-level languages.

We may decide that we're not going to do an optimization even though
it will make some operation 10% faster because it's too risky. It's
only worth making changes if they really are justified by a significant
improvement on real-world workloads.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671