RFR: 8273972: Multi-core choke point in CMM engine (LCMSTransform.doTransform)

[Sergey Bylokhov]

On Fri, 24 Sep 2021 04:38:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Initially, the bug was discussed here:
> https://stackoverflow.com/questions/35264582/why-is-multithreading-slowing-down/35264813
> 
> The root cause is that if for some reason directly or indirectly the color transform object is shared across the threads it cannot be used for parallel color transformation because the method LCMSTransform.doTransform()  is synchronized.
> 
> This code seems to be created when the littlecms 1.x was used which was not thread-safe, but the latest version is thread safe (subject to bugs). I can check that by compiling lcms with #define CMS_NO_PTHREADS which will cause some of our tests fail here and there.
> 
> To check that transform can be used across the threads I created two quite heavyweight tests which tests different color transformations using different threads.
> 
> The fix moves the data for the native transform from the LCMSTransform object to the NativeTransform class just to simplify synchronization steps, so only one volatile read of "transform" is executed in the common path.
> 
> Result for the testcase attached to SO: https://stackoverflow.com/a/35264713
> |№ threads|Before the fix|After the fix|
> |-------------|-------------|-------------|
> |1 |  693 ms | 699 ms|
> |8 | 6641 ms| 873 ms|
> |30 |34069 ms|1034 ms|

test/jdk/sun/java2d/cmm/ColorConvertOp/MTPerLineTransformValidation.java line 32:

> 30:  * @bug 8273972
> 31:  * @summary Verifies that ColorConvertOp works fine if shared between threads
> 32:  * @run main/othervm/timeout=600 MTTransformValidation

600 is quite pessimistic, on my system both tests are executed around 1 minute, but I am not sure how it will execute on the slow mac mini, so increased the timeout.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5671