From prasanta.sadhukhan at oracle.com  Tue Dec  1 05:58:56 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Tue, 1 Dec 2015 11:28:56 +0530
Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8140530, ,
 Creating a VolatileImage with size 0,
 0 results in no longer working g2d.drawStri
In-Reply-To: <565C0C1D.3080408@oracle.com>
References: <565C0C1D.3080408@oracle.com>
Message-ID: <565D3720.8060009@oracle.com>

Modified the testcase to "fail" if IAE is not thrown
http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.01

Regards
Prasanta
On 11/30/2015 2:13 PM, prasanta sadhukhan wrote:
> Hi All,
>
> Please review a fix for jdk9
> Bug: https://bugs.openjdk.java.net/browse/JDK-8140530
> webrev: http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.00/
>
> The issue was creating a volatileImage with 0 width, height does not 
> result in IllegalArgumentException.
> But, when we try to create a non-volatile Image via 
> GraphicsConfiguration.createCompatibleImage(0,0) or a 
> BufferedImage(0,0,imagetype) it results in IAE.
> So, to maintain consistency across all image w.r.t 0 width,height, 
> createVolatileImage() should also throw IAE.
>
> In windows, creating a volatileImage with 0 width,height resulted in 
> IAE but in linux it does not.
>
> This is because XCreatePixmap() generate BadValue unless width,height 
> is nonzero but the error handler does not catch it.
> https://tronche.com/gui/x/xlib/pixmap-and-cursor/XCreatePixmap.html 
> [The width and height arguments must be nonzero, or a *BadValue* error 
> results.]
>
> I have added a check to prevent zero width,height to be used for 
> XCreatePixmap() and also throw OOME so to ask Java to throw IAE.
>
> Regards
> Prasanta

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151201/b5459264/attachment.html>

From jayathirth.d.v at oracle.com  Tue Dec  1 10:12:04 2015
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Tue, 1 Dec 2015 02:12:04 -0800 (PST)
Subject: [OpenJDK 2D-Dev] <OpenJDK 2D-Dev> Review request for JDK-8143562:
 JPEG reader returns null for getRawImageType()
Message-ID: <45125a5d-a274-4321-9510-dc0e8774d505@default>

Hi,

 

Please review following fix in JDK9:

 

Bug : https://bugs.openjdk.java.net/browse/JDK-8143562

 

Webrev : http://cr.openjdk.java.net/~jdv/8143562/webrev.00/

 

Issue : We are getting null for ImageTypeSpecifier when we use getRawImageType() API for YCbCr Image.

 

Root cause : When colorspace is YCbCr, there is no condition to create ImageTypeSpecifier in produce() function

 

Solution : Since we add RGB as default ImageType for YCbCr colorspace in getImageTypes() API. Followed same approach

                    and considering it as RGB in getRawImageType().

 

Thanks,

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151201/40f89fe9/attachment.html>

From Sergey.Bylokhov at oracle.com  Tue Dec  1 19:12:52 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 2 Dec 2015 00:42:52 +0530
Subject: [OpenJDK 2D-Dev] Review request for JDK-6967419 :
 IndexOutOfBoundsException when drawing PNGs
In-Reply-To: <73963f44-6f4b-41e0-a0a8-37e0a7ef9d4d@default>
References: <24aaf3b1-6f23-40b5-a4f2-7994bc1af7eb@default>
	<563C6FAF.3040600@oracle.com>
	<48666932-8fbd-4588-9175-07acdd24d78b@default>
	<5644DD22.2080205@oracle.com>
	<3ea69749-8b12-43ca-bb53-3db53eb8d26b@default>
	<564A5000.6040202@oracle.com>
	<73963f44-6f4b-41e0-a0a8-37e0a7ef9d4d@default>
Message-ID: <565DF134.4090207@oracle.com>

Hi, Jay.
Can you please check other writers and confirm that similar issues are 
not exists there(just try a different writers in the test)? If the 
problem exists it can be fixed as a separate issue, if everything works 
as expected nothing should be changed.

On 17.11.15 14:41, Jayathirth D V wrote:
> Hi Phil,
>
> Thanks for pointing to JDK-8041746 .
>
> _My observations:_
>
> I think with Andrew?s test case we are able to identify the problem
> submitter might have faced in JDK-6967419 . By deliberately throwing
> exception at count 30000L we are trying to reproduce scenario of
> possible IOException where client is closing the socket(probably because
> of communication problem between client & server) and IDAT chunk is
> being written. If we change count to any other number(like 10L) which
> relates to writing of data apart from IDAT chunk we don?t see any
> issue(no exception and cache is closed properly).
>
> This might explain why submitter is seeing 7 out of 20 fail.
>
> Also by using the test case we are able to see flushedPos going past by
> 4 bytes to Pos when ios.close() is called as mentioned by submitter in
> JDK-6967419. So catching the IOException and updating ?startPos? value,
> will not result in IndexOutOfBoundsException and ios.close() will be
> performed properly.
>
> Please let us know your inputs.
>
> Thanks,
>
> Jay
>
> *From:*Phil Race
> *Sent:* Tuesday, November 17, 2015 3:22 AM
> *To:* Jayathirth D V
> *Cc:* Prasanta Sadhukhan; 2d-dev at openjdk.java.net
> *Subject:* Re: Review request for JDK-6967419 :
> IndexOutOfBoundsException when drawing PNGs
>
> This one reads like it should be obvious but I find it less so ..
> The unsatisfying part is that we do not seem to know what caused
> the IOException in the customer case.
>
> Andrew came up with a way to reproduce the symptoms but we really
> don't know what caused the exception in the case of the submitter.
> It does not seem likely he was 'deliberately' throwing an exception to
> mess up his own application.
>
> I just found this : https://bugs.openjdk.java.net/browse/JDK-8041746
>
> The interesting part is that this bug (the one you are working on)
> the submitter also wrote that he was using "a ServletOutputStream"
>
> So consequently I wonder if it was something like what is described in
> 8041746 is going on here. It could explain how he sees 7 out of 20 fail.
>
> Please take a look at that one to have a think about it.
> Would your fix help that real world case ?
>
> -phil.
>
> On 11/12/2015 08:11 PM, Jayathirth D V wrote:
>
>     Hi Phil,
>
>     I have added public evaluation in bug. Please review.
>
>     Thanks,
>
>     Jay
>
>     *From:*Philip Race
>     *Sent:* Friday, November 13, 2015 12:11 AM
>     *To:* Jayathirth D V
>     *Cc:* Prasanta Sadhukhan; 2d-dev at openjdk.java.net
>     <mailto:2d-dev at openjdk.java.net>
>     *Subject:* Re: Review request for JDK-6967419 :
>     IndexOutOfBoundsException when drawing PNGs
>
>     Please add a *public* evaluation to the bug report. I will look at
>     it more then ..
>
>     -phil.
>
>     On 11/6/15, 2:20 AM, Jayathirth D V wrote:
>
>         Hi Prasanta,
>
>         As discussed, only in case of write_IDAT there is finally block
>         which calls ios.finish() which internally calls seek() with
>         improper startPos. In other cases we are not trying to access
>         improper startPos because there is no call to ios.finish(). We
>         can verify this behavior by changing logic where we throw
>         IOException in test case.
>
>         And I have modified test to not catch IOBE as per your
>         suggestion. Please find updated Webrev link:
>
>         http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.01/
>         <http://cr.openjdk.java.net/%7Erchamyal/jay/6967419/webrev.01/>
>
>         Thanks,
>
>         Jay
>
>         *From:*prasanta sadhukhan
>         *Sent:* Friday, November 06, 2015 2:45 PM
>         *To:* Jayathirth D V; 2d-dev at openjdk.java.net
>         <mailto:2d-dev at openjdk.java.net>
>         *Cc:* Philip Race
>         *Subject:* Re: Review request for JDK-6967419 :
>         IndexOutOfBoundsException when drawing PNGs
>
>         Hi Jay,
>
>         looks ok but
>         I guess you need to do the same for finish() method too in
>         similar way you did for finishChunk() as finish() is called from
>         write_IHDR, write_CHRM etc and it calls flushBefore().
>         Also, I guess you should not consume IOB Exception and let it be
>         thrown to user instead of RuntimeException after catching IOBE.
>
>         Regards
>         Prasanta
>
>         On 11/5/2015 5:25 PM, Jayathirth D V wrote:
>
>             Hello All,
>
>             Please review following fix in jdk9:
>
>             Bug : https://bugs.openjdk.java.net/browse/JDK-6967419
>
>             Webrev :
>             http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.00/
>             <http://cr.openjdk.java.net/%7Erchamyal/jay/6967419/webrev.00/>
>
>             Bug : IndexOutOfBoundsException when drawing PNGs
>
>             Root cause : When user intentionally throws IO Exception
>             while write is happening.
>                                        We call ios.finish() in finally
>             block of write_IDAT() which internally goes to
>             finishChunk(). But the startPos of the chunk is still
>             pointing to present IDAT chunk but flushedPos(streamPos) is
>             pointing to end of  IDAT chunk.
>                                        So in finishChunk(), startPos
>             will be less than flushedPos. This is causing
>             IndexOutOfBoundException in stream.seek() and cache is not
>             closed.
>
>             Solution : If IOException is thrown by user, catch the
>             exception while write is happening and update startPos to
>             streamPos. So that when seek() happens in finishChunk() we
>             don?t see IndexOutOfBoundsException and cache is closed
>             properly.
>
>             Thanks,
>
>             Jay
>


-- 
Best regards, Sergey.


From james.graham at oracle.com  Tue Dec  1 22:54:22 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 1 Dec 2015 14:54:22 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8076529: Marlin antialiasing renderer
 integration
In-Reply-To: <CAKjRUT5PZC0nEMAap=HnvQRbd3DqheEVLHYjyH7K-hgwcGbJgg@mail.gmail.com>
References: <564FBCED.4030501@oracle.com> <565363DA.40505@oracle.com>
	<CAKjRUT5PZC0nEMAap=HnvQRbd3DqheEVLHYjyH7K-hgwcGbJgg@mail.gmail.com>
Message-ID: <565E251E.6030008@oracle.com>

I don't know of any way of providing that requirement in a test case - 
Phil?  Sergey?

If the machine doesn't have that much memory, I'm guessing that most of 
the OS's have some system of virtual memory that will get used, but it 
will add to the time the test takes due to paging.

Is 2G/3G something the test machines are not likely to have at this point?

		...jim

On 11/27/15 1:54 AM, Laurent Bourg?s wrote:
> Hi,
>
> I fixed the CrashTest class to add jtreg tags and it passed with jtreg
> on my laptop.
>
> It needs 512mb for the heap but also 2Gb for off-heap arrays so the
> machine should have at least 3Gb of memory.
> Do you know how to define such requirements (@requires) ?
>
> Here is the webrev:
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-s5.0/
>
> Do you have already a bug id ?
>
> Laurent
>
> 2015-11-23 20:07 GMT+01:00 Sergey Bylokhov <Sergey.Bylokhov at oracle.com
> <mailto:Sergey.Bylokhov at oracle.com>>:
>
>     Hi, Jim.
>     It seems that the tests cannot be run via jtreg because of "package
>     marlin" in it. Also as far as I know there is a possibility in the
>     latest jtreg to filter out the system based on the ram, so is it
>     possible to make CrashTest.java automated?
>


From james.graham at oracle.com  Tue Dec  1 23:10:13 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 1 Dec 2015 15:10:13 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8076529: Marlin antialiasing renderer
 integration
In-Reply-To: <CAKjRUT5PZC0nEMAap=HnvQRbd3DqheEVLHYjyH7K-hgwcGbJgg@mail.gmail.com>
References: <564FBCED.4030501@oracle.com> <565363DA.40505@oracle.com>
	<CAKjRUT5PZC0nEMAap=HnvQRbd3DqheEVLHYjyH7K-hgwcGbJgg@mail.gmail.com>
Message-ID: <565E28D5.7030004@oracle.com>

Here is a bugid for this issue: 
https://bugs.openjdk.java.net/browse/JDK-8144446

Please start a new review thread referencing that bug id (see the 
various "RFR" threads in the 2d-dev archives for a template).  We should 
discuss all new work on Marlin under separate threads with bugids...

			...jim

On 11/27/15 1:54 AM, Laurent Bourg?s wrote:
> Hi,
>
> I fixed the CrashTest class to add jtreg tags and it passed with jtreg
> on my laptop.
>
> It needs 512mb for the heap but also 2Gb for off-heap arrays so the
> machine should have at least 3Gb of memory.
> Do you know how to define such requirements (@requires) ?
>
> Here is the webrev:
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-s5.0/
>
> Do you have already a bug id ?
>
> Laurent
>
> 2015-11-23 20:07 GMT+01:00 Sergey Bylokhov <Sergey.Bylokhov at oracle.com
> <mailto:Sergey.Bylokhov at oracle.com>>:
>
>     Hi, Jim.
>     It seems that the tests cannot be run via jtreg because of "package
>     marlin" in it. Also as far as I know there is a possibility in the
>     latest jtreg to filter out the system based on the ram, so is it
>     possible to make CrashTest.java automated?
>


From prasanta.sadhukhan at oracle.com  Wed Dec  2 10:35:34 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Wed, 2 Dec 2015 16:05:34 +0530
Subject: [OpenJDK 2D-Dev] [9] RFR: Test
 closed/javax/print/attribute/Services_getDocFl.java fails with
 NullpointerException
Message-ID: <565EC976.5060104@oracle.com>

Hi All,

Please review a fix for jdk9
Bug: https://bugs.openjdk.java.net/browse/JDK-8040139
webrev: http://cr.openjdk.java.net/~jdv/prasanta/8040139/webrev.00/

It seems if a IPP printer is not accessible, 
PrintServiceLookup.lookupPrintServices will return the printer service 
but PrintService.getSupportedDocFlavors() will return null
since for the printer there is no way to answer the questions as to what 
it supports and if after that someone tries to access flavors.length it 
will cause NPE.
However, as per spec
/https://docs.oracle.com/javase/8/docs/api/index.html?javax/print/PrintService.html//
//it clearly says, //
/

/Returns:/
    /Array of supported doc flavors, should have at least one element./


so returning null is a violation of spec.
I have added a fix to return DocService.SERVICE_FORMATTED flavor for 
such case.

Could not add a reg testcase as it will need an inaccessible printer.

Regards
Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151202/b357ca12/attachment.html>

From philip.race at oracle.com  Wed Dec  2 18:38:36 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 02 Dec 2015 10:38:36 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8144526: Remove Marlin logging use of deleted
	internal API
Message-ID: <565F3AAC.4080004@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8144526

MarlinUtils uses internal API that has been deleted as part of the new 
StackWalker.
I need to integrate right now and I don't have time to re-write this.
In any case it is only used to get a class name to put into a logging 
message which
is currently completely disabled anyway (no way to enable without 
recompiling).

So I changing the method that it always returns unknown and we can 
rework afterwards.

My diff is below :-

-phil.

hg diff MarlinUtils.java
diff --git 
a/src/java.desktop/share/classes/sun/java2d/marlin/MarlinUtils.java 
b/src/java.desktop/share/classes/sun/java2d/marlin/MarlinUtils.java
--- a/src/java.desktop/share/classes/sun/java2d/marlin/MarlinUtils.java
+++ b/src/java.desktop/share/classes/sun/java2d/marlin/MarlinUtils.java
@@ -25,8 +25,6 @@

  package sun.java2d.marlin;

-import jdk.internal.misc.JavaLangAccess;
-import jdk.internal.misc.SharedSecrets;

  public final class MarlinUtils {
      // TODO: use sun.util.logging.PlatformLogger once in JDK9
@@ -70,31 +68,6 @@
          String sourceClassName = null;
          String sourceMethodName = null;

-        JavaLangAccess access = SharedSecrets.getJavaLangAccess();
-        Throwable throwable = new Throwable();
-        int depth = access.getStackTraceDepth(throwable);
-
-        boolean lookingForClassName = true;
-        for (int ix = 0; ix < depth; ix++) {
-            // Calling getStackTraceElement directly prevents the VM
-            // from paying the cost of building the entire stack frame.
-            StackTraceElement frame = 
access.getStackTraceElement(throwable, ix);
-            String cname = frame.getClassName();
-            if (lookingForClassName) {
-                // Skip all frames until we have found the first frame 
having the class name.
-                if (cname.equals(className)) {
-                    lookingForClassName = false;
-                }
-            } else {
-                if (!cname.equals(className)) {
-                    // We've found the relevant frame.
-                    sourceClassName = cname;
-                    sourceMethodName = frame.getMethodName();
-                    break;
-                }
-            }
-        }
-
          if (sourceClassName != null) {
              return sourceClassName + " " + sourceMethodName;
          } else {




From james.graham at oracle.com  Wed Dec  2 18:47:38 2015
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 2 Dec 2015 10:47:38 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8144526: Remove Marlin logging use of
 deleted internal API
In-Reply-To: <565F3AAC.4080004@oracle.com>
References: <565F3AAC.4080004@oracle.com>
Message-ID: <565F3CCA.8080407@oracle.com>

+1 - and file a follow-on bug to restore it with the new API later...

			...jim

On 12/2/15 10:38 AM, Phil Race wrote:
> https://bugs.openjdk.java.net/browse/JDK-8144526
>
> MarlinUtils uses internal API that has been deleted as part of the new
> StackWalker.
> I need to integrate right now and I don't have time to re-write this.
> In any case it is only used to get a class name to put into a logging
> message which
> is currently completely disabled anyway (no way to enable without
> recompiling).
>
> So I changing the method that it always returns unknown and we can
> rework afterwards.
>
> My diff is below :-
>
> -phil.
>
> hg diff MarlinUtils.java
> diff --git
> a/src/java.desktop/share/classes/sun/java2d/marlin/MarlinUtils.java
> b/src/java.desktop/share/classes/sun/java2d/marlin/MarlinUtils.java
> --- a/src/java.desktop/share/classes/sun/java2d/marlin/MarlinUtils.java
> +++ b/src/java.desktop/share/classes/sun/java2d/marlin/MarlinUtils.java
> @@ -25,8 +25,6 @@
>
>   package sun.java2d.marlin;
>
> -import jdk.internal.misc.JavaLangAccess;
> -import jdk.internal.misc.SharedSecrets;
>
>   public final class MarlinUtils {
>       // TODO: use sun.util.logging.PlatformLogger once in JDK9
> @@ -70,31 +68,6 @@
>           String sourceClassName = null;
>           String sourceMethodName = null;
>
> -        JavaLangAccess access = SharedSecrets.getJavaLangAccess();
> -        Throwable throwable = new Throwable();
> -        int depth = access.getStackTraceDepth(throwable);
> -
> -        boolean lookingForClassName = true;
> -        for (int ix = 0; ix < depth; ix++) {
> -            // Calling getStackTraceElement directly prevents the VM
> -            // from paying the cost of building the entire stack frame.
> -            StackTraceElement frame =
> access.getStackTraceElement(throwable, ix);
> -            String cname = frame.getClassName();
> -            if (lookingForClassName) {
> -                // Skip all frames until we have found the first frame
> having the class name.
> -                if (cname.equals(className)) {
> -                    lookingForClassName = false;
> -                }
> -            } else {
> -                if (!cname.equals(className)) {
> -                    // We've found the relevant frame.
> -                    sourceClassName = cname;
> -                    sourceMethodName = frame.getMethodName();
> -                    break;
> -                }
> -            }
> -        }
> -
>           if (sourceClassName != null) {
>               return sourceClassName + " " + sourceMethodName;
>           } else {
>
>


From bourges.laurent at gmail.com  Wed Dec  2 19:04:48 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 2 Dec 2015 20:04:48 +0100
Subject: [OpenJDK 2D-Dev] RFR: 8144526: Remove Marlin logging use of
 deleted internal API
In-Reply-To: <565F3AAC.4080004@oracle.com>
References: <565F3AAC.4080004@oracle.com>
Message-ID: <CAKjRUT4LeJNW=5FqkuF75LuDB+p4=PW47sZeCJJyBmqkb1mqYA@mail.gmail.com>

Phil,
No problem. I mentioned some time ago that this tracing method is somewhat
not really useful anymore.

I will take care of the clean up afterwards.

Laurent
Le 2 d?c. 2015 19:41, "Phil Race" <philip.race at oracle.com> a ?crit :

> https://bugs.openjdk.java.net/browse/JDK-8144526
>
> MarlinUtils uses internal API that has been deleted as part of the new
> StackWalker.
> I need to integrate right now and I don't have time to re-write this.
> In any case it is only used to get a class name to put into a logging
> message which
> is currently completely disabled anyway (no way to enable without
> recompiling).
>
> So I changing the method that it always returns unknown and we can rework
> afterwards.
>
> My diff is below :-
>
> -phil.
>
> hg diff MarlinUtils.java
> diff --git
> a/src/java.desktop/share/classes/sun/java2d/marlin/MarlinUtils.java
> b/src/java.desktop/share/classes/sun/java2d/marlin/MarlinUtils.java
> --- a/src/java.desktop/share/classes/sun/java2d/marlin/MarlinUtils.java
> +++ b/src/java.desktop/share/classes/sun/java2d/marlin/MarlinUtils.java
> @@ -25,8 +25,6 @@
>
>  package sun.java2d.marlin;
>
> -import jdk.internal.misc.JavaLangAccess;
> -import jdk.internal.misc.SharedSecrets;
>
>  public final class MarlinUtils {
>      // TODO: use sun.util.logging.PlatformLogger once in JDK9
> @@ -70,31 +68,6 @@
>          String sourceClassName = null;
>          String sourceMethodName = null;
>
> -        JavaLangAccess access = SharedSecrets.getJavaLangAccess();
> -        Throwable throwable = new Throwable();
> -        int depth = access.getStackTraceDepth(throwable);
> -
> -        boolean lookingForClassName = true;
> -        for (int ix = 0; ix < depth; ix++) {
> -            // Calling getStackTraceElement directly prevents the VM
> -            // from paying the cost of building the entire stack frame.
> -            StackTraceElement frame =
> access.getStackTraceElement(throwable, ix);
> -            String cname = frame.getClassName();
> -            if (lookingForClassName) {
> -                // Skip all frames until we have found the first frame
> having the class name.
> -                if (cname.equals(className)) {
> -                    lookingForClassName = false;
> -                }
> -            } else {
> -                if (!cname.equals(className)) {
> -                    // We've found the relevant frame.
> -                    sourceClassName = cname;
> -                    sourceMethodName = frame.getMethodName();
> -                    break;
> -                }
> -            }
> -        }
> -
>          if (sourceClassName != null) {
>              return sourceClassName + " " + sourceMethodName;
>          } else {
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151202/67bebce8/attachment.html>

From james.graham at oracle.com  Wed Dec  2 19:08:19 2015
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 2 Dec 2015 11:08:19 -0800
Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8140530, ,
 Creating a VolatileImage with size 0,
 0 results in no longer working g2d.drawStri
In-Reply-To: <565D3720.8060009@oracle.com>
References: <565C0C1D.3080408@oracle.com> <565D3720.8060009@oracle.com>
Message-ID: <565F41A3.3050309@oracle.com>

Hi Prasanta,

(On a practical note, in the HTML version of your message, the text said 
"webrev.01", but the link in the href pointed to "webrev.00" so I sat 
there wondering why the changes you noted weren't there until I realized 
that I was still looking at webrev.00 and had to manually enter 
webrev.01 in the browser to see the new code...)

Have you run your new test on all platforms to make sure that it 
succeeds (by throwing IAE) on all currently supported/tested platorms?

It seems, from the comment, that one issue is that X11 has a special 
need in that if we make it through to the native code with 0,0 arguments 
and attempt to create a pixmap of 0,0 then we get an X11 error so I'm OK 
with the native code having its own check for protection against the X11 
error. But, for consistency, shouldn't the 0,0 be detected and and IAE 
thrown at a much higher level shared by all platforms so that no 
platform can accidentally allow 0,0?  Otherwise we have to make sure 
that each and every current platform and each and every future platform 
port contains these checks to satisfy the new behavior expectation.

Apparently, somewhere above the native method there is a check that 
converts OOME to IAE - is that in shared code or in the X11-specific code?

			...jim

On 11/30/15 9:58 PM, prasanta sadhukhan wrote:
> Modified the testcase to "fail" if IAE is not thrown
> http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.01
>
> Regards
> Prasanta
> On 11/30/2015 2:13 PM, prasanta sadhukhan wrote:
>> Hi All,
>>
>> Please review a fix for jdk9
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8140530
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.00/
>>
>> The issue was creating a volatileImage with 0 width, height does not
>> result in IllegalArgumentException.
>> But, when we try to create a non-volatile Image via
>> GraphicsConfiguration.createCompatibleImage(0,0) or a
>> BufferedImage(0,0,imagetype) it results in IAE.
>> So, to maintain consistency across all image w.r.t 0 width,height,
>> createVolatileImage() should also throw IAE.
>>
>> In windows, creating a volatileImage with 0 width,height resulted in
>> IAE but in linux it does not.
>>
>> This is because XCreatePixmap() generate BadValue unless width,height
>> is nonzero but the error handler does not catch it.
>> https://tronche.com/gui/x/xlib/pixmap-and-cursor/XCreatePixmap.html
>> [The width and height arguments must be nonzero, or a *BadValue* error
>> results.]
>>
>> I have added a check to prevent zero width,height to be used for
>> XCreatePixmap() and also throw OOME so to ask Java to throw IAE.
>>
>> Regards
>> Prasanta
>


From Sergey.Bylokhov at oracle.com  Wed Dec  2 19:20:50 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 3 Dec 2015 00:50:50 +0530
Subject: [OpenJDK 2D-Dev] RFR: 8144526: Remove Marlin logging use of
 deleted internal API
In-Reply-To: <565F3CCA.8080407@oracle.com>
References: <565F3AAC.4080004@oracle.com> <565F3CCA.8080407@oracle.com>
Message-ID: <565F4492.3090908@oracle.com>

On 03.12.15 0:17, Jim Graham wrote:
> +1 - and file a follow-on bug to restore it with the new API later...

+1

>
>              ...jim
>
> On 12/2/15 10:38 AM, Phil Race wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8144526
>>
>> MarlinUtils uses internal API that has been deleted as part of the new
>> StackWalker.
>> I need to integrate right now and I don't have time to re-write this.
>> In any case it is only used to get a class name to put into a logging
>> message which
>> is currently completely disabled anyway (no way to enable without
>> recompiling).
>>
>> So I changing the method that it always returns unknown and we can
>> rework afterwards.
>>
>> My diff is below :-
>>
>> -phil.
>>
>> hg diff MarlinUtils.java
>> diff --git
>> a/src/java.desktop/share/classes/sun/java2d/marlin/MarlinUtils.java
>> b/src/java.desktop/share/classes/sun/java2d/marlin/MarlinUtils.java
>> --- a/src/java.desktop/share/classes/sun/java2d/marlin/MarlinUtils.java
>> +++ b/src/java.desktop/share/classes/sun/java2d/marlin/MarlinUtils.java
>> @@ -25,8 +25,6 @@
>>
>>   package sun.java2d.marlin;
>>
>> -import jdk.internal.misc.JavaLangAccess;
>> -import jdk.internal.misc.SharedSecrets;
>>
>>   public final class MarlinUtils {
>>       // TODO: use sun.util.logging.PlatformLogger once in JDK9
>> @@ -70,31 +68,6 @@
>>           String sourceClassName = null;
>>           String sourceMethodName = null;
>>
>> -        JavaLangAccess access = SharedSecrets.getJavaLangAccess();
>> -        Throwable throwable = new Throwable();
>> -        int depth = access.getStackTraceDepth(throwable);
>> -
>> -        boolean lookingForClassName = true;
>> -        for (int ix = 0; ix < depth; ix++) {
>> -            // Calling getStackTraceElement directly prevents the VM
>> -            // from paying the cost of building the entire stack frame.
>> -            StackTraceElement frame =
>> access.getStackTraceElement(throwable, ix);
>> -            String cname = frame.getClassName();
>> -            if (lookingForClassName) {
>> -                // Skip all frames until we have found the first frame
>> having the class name.
>> -                if (cname.equals(className)) {
>> -                    lookingForClassName = false;
>> -                }
>> -            } else {
>> -                if (!cname.equals(className)) {
>> -                    // We've found the relevant frame.
>> -                    sourceClassName = cname;
>> -                    sourceMethodName = frame.getMethodName();
>> -                    break;
>> -                }
>> -            }
>> -        }
>> -
>>           if (sourceClassName != null) {
>>               return sourceClassName + " " + sourceMethodName;
>>           } else {
>>
>>


-- 
Best regards, Sergey.


From gnu.andrew at redhat.com  Wed Dec  2 21:26:00 2015
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 2 Dec 2015 16:26:00 -0500 (EST)
Subject: [OpenJDK 2D-Dev] <AWT Dev> [rfc]Stream doesn't reset mark in
 finally
In-Reply-To: <56585330.7050500@redhat.com>
References: <563DB869.80600@redhat.com> <5640957C.10702@oracle.com>
	<56449312.2000005@oracle.com> <564CB29C.10200@redhat.com>
	<56542B29.90202@redhat.com>
	<1720362320.17383226.1448474028843.JavaMail.zimbra@redhat.com>
	<56585330.7050500@redhat.com>
Message-ID: <1423088524.22543327.1449091560616.JavaMail.zimbra@redhat.com>

----- Original Message -----
> On 11/25/2015 06:53 PM, Andrew Hughes wrote:
> > ----- Original Message -----
> >> On 11/18/2015 06:17 PM, Jiri Vanek wrote:
> >>> On 11/12/2015 02:24 PM, Sergey Bylokhov wrote:
> >>>> Hi, Jiri.
> >>>> This is a valid point, did you file a new CR for this issue?
> >>
> >> ping?
> >>
> >>>>
> >>>
> >>> Hello!
> >>>
> >>> here it is:
> >>> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/
> >>>
> >>> Patch:
> >>> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/webrev/
> >>> and reprodcuer
> >>> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/MarkTryFinallyReproducer.java
> >>>
> >>>
> >>> Reproducer can be easily turned to jtreg if wonted.
> >>>
> >>> The patch is for 8, but is valid also for 9, except the path to file.
> >>> I will adapt it to 9 once you are ok with it (or you may on your own,
> >>> depends on you)
> >>>
> >>> J.
> >>>
> >>>
> >>>> On 09.11.15 15:45, Alexander Scherbatiy wrote:
> >>>>> On 11/7/2015 11:38 AM, Jiri Vanek wrote:
> >>>>>> Hello!
> >>>>>>
> >>>>>> Looking to imageIO.java (if this is bad thread, please redirect me!)
> >>>>>
> >>>>>       2d-dev alias should be also the right place to ask image related
> >>>>> questions in AWT.
> >>>>>
> >>>>>      Thanks,
> >>>>>      Alexandr.
> >>>>>
> >>>>>> when reading images
> >>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/javax/imageio/ImageIO.java#l543
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> and ending at:
> >>>>>>
> >>>>>>                  // Perform mark/reset as a defensive measure
> >>>>>>                  // even though plug-ins are supposed to take
> >>>>>>                  // care of it.
> >>>>>>                  boolean canDecode = false;
> >>>>>>                  if (stream != null) {
> >>>>>>                      stream.mark();
> >>>>>>                  }
> >>>>>>                  canDecode = spi.canDecodeInput(input);
> >>>>>>                  if (stream != null) {
> >>>>>>                      stream.reset();
> >>>>>>                  }
> >>>>>>                  return canDecode;
> >>>>>>
> >>>>>> I'm wondering, why  stream.reset(); is not in finaly  block:
> >>>>>>
> >>>>>> // Perform mark/reset as a defensive measure
> >>>>>> // even though plug-ins are supposed to take
> >>>>>> // care of it.
> >>>>>> boolean canDecode = false;
> >>>>>> if (stream != null) {
> >>>>>> stream.mark();
> >>>>>> }
> >>>>>> try{
> >>>>>>      canDecode = spi.canDecodeInput(input);
> >>>>>> } finally {
> >>>>>>      if (stream != null) {
> >>>>>>          stream.reset();
> >>>>>>      }
> >>>>>> }
> >>>>>> return canDecode;
> >>>>>>
> >>>>>>
> >>>>>> Eg png and bmp decoders can are throwing IIOException when header is
> >>>>>> corrutped. That pretty definitely sure killer of  stream mark stacks.
> >>>>>> You yourselves write  : //Perform mark/reset as a defensive measure
> >>>>>> even though plug-ins are supposed to take care of it.
> >>>>>> So if densive, then try/finaly please.
> >>>>>>
> >>>>>> I did not check if this changed in 9 but if not....Please. This is
> >>>>>> makig work on custom image plugins, for image formats which just wraps
> >>>>>> another bmp/png and are expecting corrupted headers preatty hards.
> >>>>>>
> >>>>>>
> >>>>>> J.
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> > I've filed https://bugs.openjdk.java.net/browse/JDK-8144071 for this.
> 
> Here you go!
> 
> https://jvanek.fedorapeople.org/oracle/jdk9/webrevs/resetInTryFinally/v2/
> >
> > The change looks good to me. I can confirm the reproducer fails
> > on OpenJDK 6, 7 and 8:
> >
> > Exception in thread "main" java.lang.RuntimeException: exeption from call
> > to canDecodeInput in ImageIO corrupted stack in ImageInputStream
> > 	at MarkTryFinallyReproducer.main(MarkTryFinallyReproducer.java:317)
> >
> > I suggest the test case is converted to jtreg and the patch to
> done
> 
> > OpenJDK 9 for a new webrev. Once that is posted, I can commit
> 
> done
> > the change.
> >
> 
> TYVM!
> 
> 
> I run all jtregs, and looked ok.
>   J.
> 
> 

Thanks. I cleaned up the test case formatting a little and
pushed the change:

http://hg.openjdk.java.net/jdk9/client/jdk/rev/284925b520f1

Once it's made it to the master jdk9 repository and had time
to soak there, you probably want to suggest it for backport to 8u.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From prasanta.sadhukhan at oracle.com  Thu Dec  3 07:18:18 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Thu, 3 Dec 2015 12:48:18 +0530
Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8140530, ,
 Creating a VolatileImage with size 0,
 0 results in no longer working g2d.drawStri
In-Reply-To: <565F41A3.3050309@oracle.com>
References: <565C0C1D.3080408@oracle.com> <565D3720.8060009@oracle.com>
	<565F41A3.3050309@oracle.com>
Message-ID: <565FECBA.9090604@oracle.com>

Hi Jim,

On 12/3/2015 12:38 AM, Jim Graham wrote:
> Hi Prasanta,
>
> (On a practical note, in the HTML version of your message, the text 
> said "webrev.01", but the link in the href pointed to "webrev.00" so I 
> sat there wondering why the changes you noted weren't there until I 
> realized that I was still looking at webrev.00 and had to manually 
> enter webrev.01 in the browser to see the new code...)
>
> Have you run your new test on all platforms to make sure that it 
> succeeds (by throwing IAE) on all currently supported/tested platorms?
>
IAE was already been thrown for windows and mac. It was not working for 
linux only.
> It seems, from the comment, that one issue is that X11 has a special 
> need in that if we make it through to the native code with 0,0 
> arguments and attempt to create a pixmap of 0,0 then we get an X11 
> error so I'm OK with the native code having its own check for 
> protection against the X11 error. But, for consistency, shouldn't the 
> 0,0 be detected and and IAE thrown at a much higher level shared by 
> all platforms so that no platform can accidentally allow 0,0?  
> Otherwise we have to make sure that each and every current platform 
> and each and every future platform port contains these checks to 
> satisfy the new behavior expectation.
>
> Apparently, somewhere above the native method there is a check that 
> converts OOME to IAE - is that in shared code or in the X11-specific 
> code?
It is not a direct conversion from OOME to IAE. Basically, the Java will 
try to create a accelerated surface and if it cannot, it creates a 
backup BufferedImage via createCompatibleImage() which calls 
createCompatibleWritableRaster() and that function has a check for 0 
width,height which throws IAE.

Code wise flow:
VolatileSurfaceManager.initialize() will check for accelerated surface 
via initAcceleratedSurface() which goes to different pipeline for 
different platforms.

In windows, D3DVolatileSurfaceManager.java#initAcceleratedSurface() will 
call D3DSurfaceData.createData() which calls initSurface() which 
initializes surface by calling "native" initSurfaceNow() which returns 
false for 0 width.height. D3DSurfaceData throws InvalidPipeException to 
D3DVolatileSurfaceManager#initAcceleratedSurface()  which marks 
accelerated surface as null in that case so Java will fall back to 
BufferedImage as explained above.

In mac, CGLVolatileSurfaceManager.jaav#initAcceleratedSurface() will get 
OOM from CGlSurfaceData.createData() which calls native initFBObject() 
which returns false

In linux, native was not throwing any issue even though it does not 
utilise 0 width,height so Java still assumes it is working with 
accelerated surface so will not try to create backup BufferedImage 
surface so cannot throw IAE.
My fix will let native throw OOM to 
XRVolatileSurfaceManager.java#initAcceleratedSurface() so that it knows 
it fails to create accelerated surface and has to fall back to 
BufferedImage surface and then the IAE will be thrown from
createCompatibleWritableRaster()


If you think it's ok, we can catch 0 width,height in SunVolatileImage 
constructor before it calls VolatileSurfacemaanger. initialize() so that 
it gets trapped  at higher level? Please advise.

Regards
Prasanta

>
>             ...jim
>
> On 11/30/15 9:58 PM, prasanta sadhukhan wrote:
>> Modified the testcase to "fail" if IAE is not thrown
>> http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.01
>>
>> Regards
>> Prasanta
>> On 11/30/2015 2:13 PM, prasanta sadhukhan wrote:
>>> Hi All,
>>>
>>> Please review a fix for jdk9
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8140530
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.00/
>>>
>>> The issue was creating a volatileImage with 0 width, height does not
>>> result in IllegalArgumentException.
>>> But, when we try to create a non-volatile Image via
>>> GraphicsConfiguration.createCompatibleImage(0,0) or a
>>> BufferedImage(0,0,imagetype) it results in IAE.
>>> So, to maintain consistency across all image w.r.t 0 width,height,
>>> createVolatileImage() should also throw IAE.
>>>
>>> In windows, creating a volatileImage with 0 width,height resulted in
>>> IAE but in linux it does not.
>>>
>>> This is because XCreatePixmap() generate BadValue unless width,height
>>> is nonzero but the error handler does not catch it.
>>> https://tronche.com/gui/x/xlib/pixmap-and-cursor/XCreatePixmap.html
>>> [The width and height arguments must be nonzero, or a *BadValue* error
>>> results.]
>>>
>>> I have added a check to prevent zero width,height to be used for
>>> XCreatePixmap() and also throw OOME so to ask Java to throw IAE.
>>>
>>> Regards
>>> Prasanta
>>



From jayathirth.d.v at oracle.com  Thu Dec  3 09:31:01 2015
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Thu, 3 Dec 2015 01:31:01 -0800 (PST)
Subject: [OpenJDK 2D-Dev] Review request for JDK-6967419 :
 IndexOutOfBoundsException when drawing PNGs
In-Reply-To: <565DF134.4090207@oracle.com>
References: <24aaf3b1-6f23-40b5-a4f2-7994bc1af7eb@default>
	<563C6FAF.3040600@oracle.com>
	<48666932-8fbd-4588-9175-07acdd24d78b@default>
	<5644DD22.2080205@oracle.com>
	<3ea69749-8b12-43ca-bb53-3db53eb8d26b@default>
	<564A5000.6040202@oracle.com>
	<73963f44-6f4b-41e0-a0a8-37e0a7ef9d4d@default>
	<565DF134.4090207@oracle.com>
Message-ID: <e787e204-e68e-485a-a3f1-3c6f1b8148c4@default>

Hi Sergey,

Thanks for your suggestion.
I verified all other image writers with present code(For WBMP after changing BufferedImageType to TYPE_BYTE_BINARY) there are no problems in them.

Cache is closed properly and we don't see IndexOutOfBoundsException.

Thanks,
Jay

-----Original Message-----
From: Sergey Bylokhov 
Sent: Wednesday, December 02, 2015 12:43 AM
To: Jayathirth D V; Philip Race
Cc: 2d-dev at openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] Review request for JDK-6967419 : IndexOutOfBoundsException when drawing PNGs

Hi, Jay.
Can you please check other writers and confirm that similar issues are not exists there(just try a different writers in the test)? If the problem exists it can be fixed as a separate issue, if everything works as expected nothing should be changed.

On 17.11.15 14:41, Jayathirth D V wrote:
> Hi Phil,
>
> Thanks for pointing to JDK-8041746 .
>
> _My observations:_
>
> I think with Andrew's test case we are able to identify the problem 
> submitter might have faced in JDK-6967419 . By deliberately throwing 
> exception at count 30000L we are trying to reproduce scenario of 
> possible IOException where client is closing the socket(probably 
> because of communication problem between client & server) and IDAT 
> chunk is being written. If we change count to any other number(like 
> 10L) which relates to writing of data apart from IDAT chunk we don't 
> see any issue(no exception and cache is closed properly).
>
> This might explain why submitter is seeing 7 out of 20 fail.
>
> Also by using the test case we are able to see flushedPos going past 
> by
> 4 bytes to Pos when ios.close() is called as mentioned by submitter in 
> JDK-6967419. So catching the IOException and updating 'startPos' 
> value, will not result in IndexOutOfBoundsException and ios.close() 
> will be performed properly.
>
> Please let us know your inputs.
>
> Thanks,
>
> Jay
>
> *From:*Phil Race
> *Sent:* Tuesday, November 17, 2015 3:22 AM
> *To:* Jayathirth D V
> *Cc:* Prasanta Sadhukhan; 2d-dev at openjdk.java.net
> *Subject:* Re: Review request for JDK-6967419 :
> IndexOutOfBoundsException when drawing PNGs
>
> This one reads like it should be obvious but I find it less so ..
> The unsatisfying part is that we do not seem to know what caused the 
> IOException in the customer case.
>
> Andrew came up with a way to reproduce the symptoms but we really 
> don't know what caused the exception in the case of the submitter.
> It does not seem likely he was 'deliberately' throwing an exception to 
> mess up his own application.
>
> I just found this : https://bugs.openjdk.java.net/browse/JDK-8041746
>
> The interesting part is that this bug (the one you are working on) the 
> submitter also wrote that he was using "a ServletOutputStream"
>
> So consequently I wonder if it was something like what is described in
> 8041746 is going on here. It could explain how he sees 7 out of 20 fail.
>
> Please take a look at that one to have a think about it.
> Would your fix help that real world case ?
>
> -phil.
>
> On 11/12/2015 08:11 PM, Jayathirth D V wrote:
>
>     Hi Phil,
>
>     I have added public evaluation in bug. Please review.
>
>     Thanks,
>
>     Jay
>
>     *From:*Philip Race
>     *Sent:* Friday, November 13, 2015 12:11 AM
>     *To:* Jayathirth D V
>     *Cc:* Prasanta Sadhukhan; 2d-dev at openjdk.java.net
>     <mailto:2d-dev at openjdk.java.net>
>     *Subject:* Re: Review request for JDK-6967419 :
>     IndexOutOfBoundsException when drawing PNGs
>
>     Please add a *public* evaluation to the bug report. I will look at
>     it more then ..
>
>     -phil.
>
>     On 11/6/15, 2:20 AM, Jayathirth D V wrote:
>
>         Hi Prasanta,
>
>         As discussed, only in case of write_IDAT there is finally block
>         which calls ios.finish() which internally calls seek() with
>         improper startPos. In other cases we are not trying to access
>         improper startPos because there is no call to ios.finish(). We
>         can verify this behavior by changing logic where we throw
>         IOException in test case.
>
>         And I have modified test to not catch IOBE as per your
>         suggestion. Please find updated Webrev link:
>
>         http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.01/
>         
> <http://cr.openjdk.java.net/%7Erchamyal/jay/6967419/webrev.01/>
>
>         Thanks,
>
>         Jay
>
>         *From:*prasanta sadhukhan
>         *Sent:* Friday, November 06, 2015 2:45 PM
>         *To:* Jayathirth D V; 2d-dev at openjdk.java.net
>         <mailto:2d-dev at openjdk.java.net>
>         *Cc:* Philip Race
>         *Subject:* Re: Review request for JDK-6967419 :
>         IndexOutOfBoundsException when drawing PNGs
>
>         Hi Jay,
>
>         looks ok but
>         I guess you need to do the same for finish() method too in
>         similar way you did for finishChunk() as finish() is called from
>         write_IHDR, write_CHRM etc and it calls flushBefore().
>         Also, I guess you should not consume IOB Exception and let it be
>         thrown to user instead of RuntimeException after catching IOBE.
>
>         Regards
>         Prasanta
>
>         On 11/5/2015 5:25 PM, Jayathirth D V wrote:
>
>             Hello All,
>
>             Please review following fix in jdk9:
>
>             Bug : https://bugs.openjdk.java.net/browse/JDK-6967419
>
>             Webrev :
>             http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.00/
>             
> <http://cr.openjdk.java.net/%7Erchamyal/jay/6967419/webrev.00/>
>
>             Bug : IndexOutOfBoundsException when drawing PNGs
>
>             Root cause : When user intentionally throws IO Exception
>             while write is happening.
>                                        We call ios.finish() in finally
>             block of write_IDAT() which internally goes to
>             finishChunk(). But the startPos of the chunk is still
>             pointing to present IDAT chunk but flushedPos(streamPos) is
>             pointing to end of  IDAT chunk.
>                                        So in finishChunk(), startPos
>             will be less than flushedPos. This is causing
>             IndexOutOfBoundException in stream.seek() and cache is not
>             closed.
>
>             Solution : If IOException is thrown by user, catch the
>             exception while write is happening and update startPos to
>             streamPos. So that when seek() happens in finishChunk() we
>             don't see IndexOutOfBoundsException and cache is closed
>             properly.
>
>             Thanks,
>
>             Jay
>


--
Best regards, Sergey.


From jvanek at redhat.com  Thu Dec  3 10:18:02 2015
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 3 Dec 2015 11:18:02 +0100
Subject: [OpenJDK 2D-Dev] <AWT Dev> [rfc]Stream doesn't reset mark in
 finally
In-Reply-To: <1423088524.22543327.1449091560616.JavaMail.zimbra@redhat.com>
References: <563DB869.80600@redhat.com> <5640957C.10702@oracle.com>
	<56449312.2000005@oracle.com> <564CB29C.10200@redhat.com>
	<56542B29.90202@redhat.com>
	<1720362320.17383226.1448474028843.JavaMail.zimbra@redhat.com>
	<56585330.7050500@redhat.com>
	<1423088524.22543327.1449091560616.JavaMail.zimbra@redhat.com>
Message-ID: <566016DA.6020602@redhat.com>

On 12/02/2015 10:26 PM, Andrew Hughes wrote:
> ----- Original Message -----
>> On 11/25/2015 06:53 PM, Andrew Hughes wrote:
>>> ----- Original Message -----
>>>> On 11/18/2015 06:17 PM, Jiri Vanek wrote:
>>>>> On 11/12/2015 02:24 PM, Sergey Bylokhov wrote:
>>>>>> Hi, Jiri.
>>>>>> This is a valid point, did you file a new CR for this issue?
>>>>
>>>> ping?
>>>>
>>>>>>
>>>>>
>>>>> Hello!
>>>>>
>>>>> here it is:
>>>>> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/
>>>>>
>>>>> Patch:
>>>>> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/webrev/
>>>>> and reprodcuer
>>>>> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/MarkTryFinallyReproducer.java
>>>>>
>>>>>
>>>>> Reproducer can be easily turned to jtreg if wonted.
>>>>>
>>>>> The patch is for 8, but is valid also for 9, except the path to file.
>>>>> I will adapt it to 9 once you are ok with it (or you may on your own,
>>>>> depends on you)
>>>>>
>>>>> J.
>>>>>
>>>>>
>>>>>> On 09.11.15 15:45, Alexander Scherbatiy wrote:
>>>>>>> On 11/7/2015 11:38 AM, Jiri Vanek wrote:
>>>>>>>> Hello!
>>>>>>>>
>>>>>>>> Looking to imageIO.java (if this is bad thread, please redirect me!)
>>>>>>>
>>>>>>>        2d-dev alias should be also the right place to ask image related
>>>>>>> questions in AWT.
>>>>>>>
>>>>>>>       Thanks,
>>>>>>>       Alexandr.
>>>>>>>
>>>>>>>> when reading images
>>>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/javax/imageio/ImageIO.java#l543
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> and ending at:
>>>>>>>>
>>>>>>>>                   // Perform mark/reset as a defensive measure
>>>>>>>>                   // even though plug-ins are supposed to take
>>>>>>>>                   // care of it.
>>>>>>>>                   boolean canDecode = false;
>>>>>>>>                   if (stream != null) {
>>>>>>>>                       stream.mark();
>>>>>>>>                   }
>>>>>>>>                   canDecode = spi.canDecodeInput(input);
>>>>>>>>                   if (stream != null) {
>>>>>>>>                       stream.reset();
>>>>>>>>                   }
>>>>>>>>                   return canDecode;
>>>>>>>>
>>>>>>>> I'm wondering, why  stream.reset(); is not in finaly  block:
>>>>>>>>
>>>>>>>> // Perform mark/reset as a defensive measure
>>>>>>>> // even though plug-ins are supposed to take
>>>>>>>> // care of it.
>>>>>>>> boolean canDecode = false;
>>>>>>>> if (stream != null) {
>>>>>>>> stream.mark();
>>>>>>>> }
>>>>>>>> try{
>>>>>>>>       canDecode = spi.canDecodeInput(input);
>>>>>>>> } finally {
>>>>>>>>       if (stream != null) {
>>>>>>>>           stream.reset();
>>>>>>>>       }
>>>>>>>> }
>>>>>>>> return canDecode;
>>>>>>>>
>>>>>>>>
>>>>>>>> Eg png and bmp decoders can are throwing IIOException when header is
>>>>>>>> corrutped. That pretty definitely sure killer of  stream mark stacks.
>>>>>>>> You yourselves write  : //Perform mark/reset as a defensive measure
>>>>>>>> even though plug-ins are supposed to take care of it.
>>>>>>>> So if densive, then try/finaly please.
>>>>>>>>
>>>>>>>> I did not check if this changed in 9 but if not....Please. This is
>>>>>>>> makig work on custom image plugins, for image formats which just wraps
>>>>>>>> another bmp/png and are expecting corrupted headers preatty hards.
>>>>>>>>
>>>>>>>>
>>>>>>>> J.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>> I've filed https://bugs.openjdk.java.net/browse/JDK-8144071 for this.
>>
>> Here you go!
>>
>> https://jvanek.fedorapeople.org/oracle/jdk9/webrevs/resetInTryFinally/v2/
>>>
>>> The change looks good to me. I can confirm the reproducer fails
>>> on OpenJDK 6, 7 and 8:
>>>
>>> Exception in thread "main" java.lang.RuntimeException: exeption from call
>>> to canDecodeInput in ImageIO corrupted stack in ImageInputStream
>>> 	at MarkTryFinallyReproducer.main(MarkTryFinallyReproducer.java:317)
>>>
>>> I suggest the test case is converted to jtreg and the patch to
>> done
>>
>>> OpenJDK 9 for a new webrev. Once that is posted, I can commit
>>
>> done
>>> the change.
>>>
>>
>> TYVM!
>>
>>
>> I run all jtregs, and looked ok.
>>    J.
>>
>>
>
> Thanks. I cleaned up the test case formatting a little and
> pushed the change:
>
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/284925b520f1
>
> Once it's made it to the master jdk9 repository and had time
> to soak there, you probably want to suggest it for backport to 8u.
>


Thank you!

J.



From philip.race at oracle.com  Thu Dec  3 19:05:39 2015
From: philip.race at oracle.com (Phil Race)
Date: Thu, 03 Dec 2015 11:05:39 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8144616: Problem building OpenJDK/harfbuzz on
	jprt
Message-ID: <56609283.9070601@oracle.com>

Some of our internal build servers only have access to an old (2.3.5) 
version
of freetype whereas harfbuzz requires 2.4.2 - maybe even later, but at 
least that.
The dependency comes from compiling in hb-ft.cc even though we do not
currently use that code since we now go via a custom JDK font driver, 
even in OpenJDK.

The fix is thus to exclude the file from the build and I have verified 
this fix on the
build system that currently fails.

--- a/make/lib/Awt2dLibraries.gmk
+++ b/make/lib/Awt2dLibraries.gmk
@@ -622,9 +622,8 @@
  ifneq ($(OPENJDK_TARGET_OS), macosx)
    LIBFONTMANAGER_EXCLUDE_FILES += harfbuzz/hb-coretext.cc
  endif
-ifndef OPENJDK
+# hb-ft.cc is not presently needed, and requires freetype 2.4.2 or later.
    LIBFONTMANAGER_EXCLUDE_FILES += harfbuzz/hb-ft.cc
-endif

  LIBFONTMANAGER_CFLAGS += $(HARFBUZZ_CFLAGS)

-phil.



From Sergey.Bylokhov at oracle.com  Thu Dec  3 19:23:15 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 4 Dec 2015 00:53:15 +0530
Subject: [OpenJDK 2D-Dev] RFR: 8144616: Problem building
 OpenJDK/harfbuzz on jprt
In-Reply-To: <56609283.9070601@oracle.com>
References: <56609283.9070601@oracle.com>
Message-ID: <566096A3.6010006@oracle.com>

Looks fine.

On 04.12.15 0:35, Phil Race wrote:
> Some of our internal build servers only have access to an old (2.3.5)
> version
> of freetype whereas harfbuzz requires 2.4.2 - maybe even later, but at
> least that.
> The dependency comes from compiling in hb-ft.cc even though we do not
> currently use that code since we now go via a custom JDK font driver,
> even in OpenJDK.
>
> The fix is thus to exclude the file from the build and I have verified
> this fix on the
> build system that currently fails.
>
> --- a/make/lib/Awt2dLibraries.gmk
> +++ b/make/lib/Awt2dLibraries.gmk
> @@ -622,9 +622,8 @@
>   ifneq ($(OPENJDK_TARGET_OS), macosx)
>     LIBFONTMANAGER_EXCLUDE_FILES += harfbuzz/hb-coretext.cc
>   endif
> -ifndef OPENJDK
> +# hb-ft.cc is not presently needed, and requires freetype 2.4.2 or later.
>     LIBFONTMANAGER_EXCLUDE_FILES += harfbuzz/hb-ft.cc
> -endif
>
>   LIBFONTMANAGER_CFLAGS += $(HARFBUZZ_CFLAGS)
>
> -phil.
>


-- 
Best regards, Sergey.


From bourges.laurent at gmail.com  Thu Dec  3 19:52:42 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 3 Dec 2015 20:52:42 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
Message-ID: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>

https://bugs.openjdk.java.net/browse/JDK-8144446

Please review that wberev fixing the CrashTest class:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.0/

Changes
- added jtreg tags (tested on my laptop): it requires 512m heap but also
2Gb off-heap ie 3Gb machine
- thow RuntimeException if not IAOB
- added comments about one test already disabled

Regards,
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151203/e8a4b5dd/attachment.html>

From vadim.pakhnushev at oracle.com  Thu Dec  3 19:54:25 2015
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Thu, 3 Dec 2015 22:54:25 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8144616: Problem building
 OpenJDK/harfbuzz on jprt
In-Reply-To: <56609283.9070601@oracle.com>
References: <56609283.9070601@oracle.com>
Message-ID: <56609DF1.8010907@oracle.com>

+1

Vadim

On 03.12.2015 22:05, Phil Race wrote:
> Some of our internal build servers only have access to an old (2.3.5) 
> version
> of freetype whereas harfbuzz requires 2.4.2 - maybe even later, but at 
> least that.
> The dependency comes from compiling in hb-ft.cc even though we do not
> currently use that code since we now go via a custom JDK font driver, 
> even in OpenJDK.
>
> The fix is thus to exclude the file from the build and I have verified 
> this fix on the
> build system that currently fails.
>
> --- a/make/lib/Awt2dLibraries.gmk
> +++ b/make/lib/Awt2dLibraries.gmk
> @@ -622,9 +622,8 @@
>  ifneq ($(OPENJDK_TARGET_OS), macosx)
>    LIBFONTMANAGER_EXCLUDE_FILES += harfbuzz/hb-coretext.cc
>  endif
> -ifndef OPENJDK
> +# hb-ft.cc is not presently needed, and requires freetype 2.4.2 or 
> later.
>    LIBFONTMANAGER_EXCLUDE_FILES += harfbuzz/hb-ft.cc
> -endif
>
>  LIBFONTMANAGER_CFLAGS += $(HARFBUZZ_CFLAGS)
>
> -phil.
>



From philip.race at oracle.com  Thu Dec  3 19:59:39 2015
From: philip.race at oracle.com (Phil Race)
Date: Thu, 03 Dec 2015 11:59:39 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
Message-ID: <56609F2B.3020101@oracle.com>

Laurent,

If you were to run this on a jigsaw EA build it would fail due to accessing
sun.java2d.pipe.RenderingEngine. I know this is "pre-existing" but 
jigsaw is coming ...

So why not update it to set call 
System.getProperty("sun.java2d.renderer.verbose");
and it'll print out the renderer in use and jigsaw will be happy.

-phil.

On 12/03/2015 11:52 AM, Laurent Bourg?s wrote:
> https://bugs.openjdk.java.net/browse/JDK-8144446
>
> Please review that wberev fixing the CrashTest class:
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.0/ 
> <http://cr.openjdk.java.net/%7Elbourges/marlin/marlin-8144446.0/>
>
> Changes
> - added jtreg tags (tested on my laptop): it requires 512m heap but 
> also 2Gb off-heap ie 3Gb machine
> - thow RuntimeException if not IAOB
> - added comments about one test already disabled
>
> Regards,
> Laurent Bourg?s



From bourges.laurent at gmail.com  Thu Dec  3 20:58:19 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 3 Dec 2015 21:58:19 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <56609F2B.3020101@oracle.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
Message-ID: <CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>

Phil,

If you were to run this on a jigsaw EA build it would fail due to accessing
> sun.java2d.pipe.RenderingEngine. I know this is "pre-existing" but jigsaw
> is coming ...
>

You're right, sorry !

Here is a new webrev:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.1/

Changes:
- set System property "sun.java2d.renderer.verbose" to true (to get the
renderer in use)
- removed any RenderingEngine usage

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151203/530db80e/attachment.html>

From joe.darcy at oracle.com  Thu Dec  3 21:09:21 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 3 Dec 2015 13:09:21 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8144627: Problem list
	WriteAfterAbort.java
Message-ID: <5660AF81.6090302@oracle.com>

Hello,

The test

     javax/imageio/plugins/shared/WriteAfterAbort.java

is failing and should be problem listed until the underlying problem is 
fixed (JDK-8144554).

Please review the patch below which does this.

Thanks,

-Joe

--- a/test/ProblemList.txt    Thu Dec 03 11:53:00 2015 -0800
+++ b/test/ProblemList.txt    Thu Dec 03 13:08:03 2015 -0800
@@ -308,6 +308,12 @@

  ############################################################################

+# jdk_imageio
+
+javax/imageio/plugins/shared/WriteAfterAbort.java generic-all
+
+############################################################################
+
  # jdk_swing

  ############################################################################



From philip.race at oracle.com  Thu Dec  3 21:10:46 2015
From: philip.race at oracle.com (Phil Race)
Date: Thu, 03 Dec 2015 13:10:46 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8144627: Problem list
	WriteAfterAbort.java
In-Reply-To: <5660AF81.6090302@oracle.com>
References: <5660AF81.6090302@oracle.com>
Message-ID: <5660AFD6.5030301@oracle.com>

I thought it was two tests  ?

-phil.

On 12/03/2015 01:09 PM, joe darcy wrote:
> Hello,
>
> The test
>
>     javax/imageio/plugins/shared/WriteAfterAbort.java
>
> is failing and should be problem listed until the underlying problem 
> is fixed (JDK-8144554).
>
> Please review the patch below which does this.
>
> Thanks,
>
> -Joe
>
> --- a/test/ProblemList.txt    Thu Dec 03 11:53:00 2015 -0800
> +++ b/test/ProblemList.txt    Thu Dec 03 13:08:03 2015 -0800
> @@ -308,6 +308,12 @@
>
>  ############################################################################ 
>
>
> +# jdk_imageio
> +
> +javax/imageio/plugins/shared/WriteAfterAbort.java generic-all
> +
> +############################################################################ 
>
> +
>  # jdk_swing
>
>  ############################################################################ 
>
>



From joe.darcy at oracle.com  Thu Dec  3 21:13:55 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 3 Dec 2015 13:13:55 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8144627: Problem list
	WriteAfterAbort.java
In-Reply-To: <5660AFD6.5030301@oracle.com>
References: <5660AF81.6090302@oracle.com> <5660AFD6.5030301@oracle.com>
Message-ID: <5660B093.6090809@oracle.com>

The other failing test is closed and I will send a separate (internal) 
review for that one :-)

Thanks,

-Joe

On 12/3/2015 1:10 PM, Phil Race wrote:
> I thought it was two tests  ?
>
> -phil.
>
> On 12/03/2015 01:09 PM, joe darcy wrote:
>> Hello,
>>
>> The test
>>
>>     javax/imageio/plugins/shared/WriteAfterAbort.java
>>
>> is failing and should be problem listed until the underlying problem 
>> is fixed (JDK-8144554).
>>
>> Please review the patch below which does this.
>>
>> Thanks,
>>
>> -Joe
>>
>> --- a/test/ProblemList.txt    Thu Dec 03 11:53:00 2015 -0800
>> +++ b/test/ProblemList.txt    Thu Dec 03 13:08:03 2015 -0800
>> @@ -308,6 +308,12 @@
>>
>>  ############################################################################ 
>>
>>
>> +# jdk_imageio
>> +
>> +javax/imageio/plugins/shared/WriteAfterAbort.java generic-all
>> +
>> +############################################################################ 
>>
>> +
>>  # jdk_swing
>>
>>  ############################################################################ 
>>
>>
>



From bourges.laurent at gmail.com  Thu Dec  3 21:23:53 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 3 Dec 2015 22:23:53 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144445: Maximum size checking in Marlin
 ArrayCache utility methods is not optimal
Message-ID: <CAKjRUT7=puzVxKiqEGoCae_QCcw6Nu-HBZa6LvmB=Uqcf0mcyA@mail.gmail.com>

https://bugs.openjdk.java.net/browse/JDK-8144445

Please review that webrev that improves overflow checks in ArrayCache:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144445.0/

Changes
- check 2Gb overflow in both getNewSize() and getNewLargeSize()
- check negative size / needSize (potential integer math overflow)
- fixed Stroker to use substraction and avoid integer overflow
- added ArrayCacheSizeTest class which now passes in jtreg

Jim's previous comments:
The change looks fine.
Are the long modifiers (12L, 1L, etc) really needed on the shift parameters
given that the first operand (needSize) is already a long?

 202             size = ((needSize >> 12L) + 1L) << 12L;

I prefer keeping the long modifiers to be more explicit.

Regards,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151203/18d81280/attachment.html>

From bourges.laurent at gmail.com  Thu Dec  3 21:37:18 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 3 Dec 2015 22:37:18 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144630: Use PrivilegedAction to create Thread
	in Marlin RendererStats
Message-ID: <CAKjRUT7J_YS6sUQFhQ96WVVfsZ5-RgnJQiJiLj8fgMYkNk4oWw@mail.gmail.com>

https://bugs.openjdk.java.net/browse/JDK-8144630

Please review this simple webrev that fixes the Thread creation in
RendererStats:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144630.0/

Regards,
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151203/0d1bf5cd/attachment.html>

From bourges.laurent at gmail.com  Thu Dec  3 22:17:16 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 3 Dec 2015 23:17:16 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144654: Improve Marlin logging
Message-ID: <CAKjRUT51G2n6=U1uJx+_H_ZqYjkbWKp4obwktWxEzyFZOW-zwA@mail.gmail.com>

https://bugs.openjdk.java.net/browse/JDK-8144654

Please review this webrev that fixes logging issues in Marlin:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144654.0/

Changes:
- Byte/Float/Int/ArrayCache: use logInfo instead of System.out
- MarlinConst: enableLogs uses MarlinProperties.isEnableLogs() and restore
potential doMonitors / doChecks flags
- MarlinProperties: added isEnableLogs()
- MarlinUtils: use PlatformLogger instead of Logger and removed
getCallerInfos()
- RendererContext: remove all MarlinUtils.getCallerInfos()

Best regards,
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151203/f25c6140/attachment.html>

From james.graham at oracle.com  Fri Dec  4 01:15:32 2015
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 3 Dec 2015 17:15:32 -0800
Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8140530, ,
 Creating a VolatileImage with size 0,
 0 results in no longer working g2d.drawStri
In-Reply-To: <565FECBA.9090604@oracle.com>
References: <565C0C1D.3080408@oracle.com> <565D3720.8060009@oracle.com>
	<565F41A3.3050309@oracle.com> <565FECBA.9090604@oracle.com>
Message-ID: <5660E934.1060606@oracle.com>

I think it makes sense to catch it at a higher level, but also to throw 
some type of exception from the X11 code as you do now because 
regardless of our higher level policy, the X11 implementation function 
can never succeed there...

So, my preference would be to keep the existing pieces of this fix that 
you already have and to add an explicit check and throw IAE to 
SunVolatileImage for completeness and guaranteed consistency...

			...jim

On 12/2/15 11:18 PM, prasanta sadhukhan wrote:
> Hi Jim,
>
> On 12/3/2015 12:38 AM, Jim Graham wrote:
>> Hi Prasanta,
>>
>> (On a practical note, in the HTML version of your message, the text
>> said "webrev.01", but the link in the href pointed to "webrev.00" so I
>> sat there wondering why the changes you noted weren't there until I
>> realized that I was still looking at webrev.00 and had to manually
>> enter webrev.01 in the browser to see the new code...)
>>
>> Have you run your new test on all platforms to make sure that it
>> succeeds (by throwing IAE) on all currently supported/tested platorms?
>>
> IAE was already been thrown for windows and mac. It was not working for
> linux only.
>> It seems, from the comment, that one issue is that X11 has a special
>> need in that if we make it through to the native code with 0,0
>> arguments and attempt to create a pixmap of 0,0 then we get an X11
>> error so I'm OK with the native code having its own check for
>> protection against the X11 error. But, for consistency, shouldn't the
>> 0,0 be detected and and IAE thrown at a much higher level shared by
>> all platforms so that no platform can accidentally allow 0,0?
>> Otherwise we have to make sure that each and every current platform
>> and each and every future platform port contains these checks to
>> satisfy the new behavior expectation.
>>
>> Apparently, somewhere above the native method there is a check that
>> converts OOME to IAE - is that in shared code or in the X11-specific
>> code?
> It is not a direct conversion from OOME to IAE. Basically, the Java will
> try to create a accelerated surface and if it cannot, it creates a
> backup BufferedImage via createCompatibleImage() which calls
> createCompatibleWritableRaster() and that function has a check for 0
> width,height which throws IAE.
>
> Code wise flow:
> VolatileSurfaceManager.initialize() will check for accelerated surface
> via initAcceleratedSurface() which goes to different pipeline for
> different platforms.
>
> In windows, D3DVolatileSurfaceManager.java#initAcceleratedSurface() will
> call D3DSurfaceData.createData() which calls initSurface() which
> initializes surface by calling "native" initSurfaceNow() which returns
> false for 0 width.height. D3DSurfaceData throws InvalidPipeException to
> D3DVolatileSurfaceManager#initAcceleratedSurface()  which marks
> accelerated surface as null in that case so Java will fall back to
> BufferedImage as explained above.
>
> In mac, CGLVolatileSurfaceManager.jaav#initAcceleratedSurface() will get
> OOM from CGlSurfaceData.createData() which calls native initFBObject()
> which returns false
>
> In linux, native was not throwing any issue even though it does not
> utilise 0 width,height so Java still assumes it is working with
> accelerated surface so will not try to create backup BufferedImage
> surface so cannot throw IAE.
> My fix will let native throw OOM to
> XRVolatileSurfaceManager.java#initAcceleratedSurface() so that it knows
> it fails to create accelerated surface and has to fall back to
> BufferedImage surface and then the IAE will be thrown from
> createCompatibleWritableRaster()
>
>
> If you think it's ok, we can catch 0 width,height in SunVolatileImage
> constructor before it calls VolatileSurfacemaanger. initialize() so that
> it gets trapped  at higher level? Please advise.
>
> Regards
> Prasanta
>
>>
>>             ...jim
>>
>> On 11/30/15 9:58 PM, prasanta sadhukhan wrote:
>>> Modified the testcase to "fail" if IAE is not thrown
>>> http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.01
>>>
>>> Regards
>>> Prasanta
>>> On 11/30/2015 2:13 PM, prasanta sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> Please review a fix for jdk9
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8140530
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.00/
>>>>
>>>> The issue was creating a volatileImage with 0 width, height does not
>>>> result in IllegalArgumentException.
>>>> But, when we try to create a non-volatile Image via
>>>> GraphicsConfiguration.createCompatibleImage(0,0) or a
>>>> BufferedImage(0,0,imagetype) it results in IAE.
>>>> So, to maintain consistency across all image w.r.t 0 width,height,
>>>> createVolatileImage() should also throw IAE.
>>>>
>>>> In windows, creating a volatileImage with 0 width,height resulted in
>>>> IAE but in linux it does not.
>>>>
>>>> This is because XCreatePixmap() generate BadValue unless width,height
>>>> is nonzero but the error handler does not catch it.
>>>> https://tronche.com/gui/x/xlib/pixmap-and-cursor/XCreatePixmap.html
>>>> [The width and height arguments must be nonzero, or a *BadValue* error
>>>> results.]
>>>>
>>>> I have added a check to prevent zero width,height to be used for
>>>> XCreatePixmap() and also throw OOME so to ask Java to throw IAE.
>>>>
>>>> Regards
>>>> Prasanta
>>>
>


From Sergey.Bylokhov at oracle.com  Fri Dec  4 03:41:34 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 4 Dec 2015 09:11:34 +0530
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8144627: Problem list
 WriteAfterAbort.java
In-Reply-To: <5660B093.6090809@oracle.com>
References: <5660AF81.6090302@oracle.com> <5660AFD6.5030301@oracle.com>
	<5660B093.6090809@oracle.com>
Message-ID: <56610B6E.20801@oracle.com>

Looks fine.

ps: I am glad that my test is written in a style that allowed to find a 
bug in a new plug-in.

On 04.12.15 2:43, joe darcy wrote:
> The other failing test is closed and I will send a separate (internal)
> review for that one :-)
>
> Thanks,
>
> -Joe
>
> On 12/3/2015 1:10 PM, Phil Race wrote:
>> I thought it was two tests  ?
>>
>> -phil.
>>
>> On 12/03/2015 01:09 PM, joe darcy wrote:
>>> Hello,
>>>
>>> The test
>>>
>>>     javax/imageio/plugins/shared/WriteAfterAbort.java
>>>
>>> is failing and should be problem listed until the underlying problem
>>> is fixed (JDK-8144554).
>>>
>>> Please review the patch below which does this.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> --- a/test/ProblemList.txt    Thu Dec 03 11:53:00 2015 -0800
>>> +++ b/test/ProblemList.txt    Thu Dec 03 13:08:03 2015 -0800
>>> @@ -308,6 +308,12 @@
>>>
>>>  ############################################################################
>>>
>>>
>>> +# jdk_imageio
>>> +
>>> +javax/imageio/plugins/shared/WriteAfterAbort.java generic-all
>>> +
>>> +############################################################################
>>>
>>> +
>>>  # jdk_swing
>>>
>>>  ############################################################################
>>>
>>>
>>
>


-- 
Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Fri Dec  4 06:17:47 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Fri, 4 Dec 2015 11:47:47 +0530
Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8140530, ,
 Creating a VolatileImage with size 0,
 0 results in no longer working g2d.drawStri
In-Reply-To: <5660E934.1060606@oracle.com>
References: <565C0C1D.3080408@oracle.com> <565D3720.8060009@oracle.com>
	<565F41A3.3050309@oracle.com> <565FECBA.9090604@oracle.com>
	<5660E934.1060606@oracle.com>
Message-ID: <5661300B.8080001@oracle.com>

ok. Thanks Jim .
Please review the modified webrev
http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.02/

Regards
Prasanta
On 12/4/2015 6:45 AM, Jim Graham wrote:
> I think it makes sense to catch it at a higher level, but also to 
> throw some type of exception from the X11 code as you do now because 
> regardless of our higher level policy, the X11 implementation function 
> can never succeed there...
>
> So, my preference would be to keep the existing pieces of this fix 
> that you already have and to add an explicit check and throw IAE to 
> SunVolatileImage for completeness and guaranteed consistency...
>
>             ...jim
>
> On 12/2/15 11:18 PM, prasanta sadhukhan wrote:
>> Hi Jim,
>>
>> On 12/3/2015 12:38 AM, Jim Graham wrote:
>>> Hi Prasanta,
>>>
>>> (On a practical note, in the HTML version of your message, the text
>>> said "webrev.01", but the link in the href pointed to "webrev.00" so I
>>> sat there wondering why the changes you noted weren't there until I
>>> realized that I was still looking at webrev.00 and had to manually
>>> enter webrev.01 in the browser to see the new code...)
>>>
>>> Have you run your new test on all platforms to make sure that it
>>> succeeds (by throwing IAE) on all currently supported/tested platorms?
>>>
>> IAE was already been thrown for windows and mac. It was not working for
>> linux only.
>>> It seems, from the comment, that one issue is that X11 has a special
>>> need in that if we make it through to the native code with 0,0
>>> arguments and attempt to create a pixmap of 0,0 then we get an X11
>>> error so I'm OK with the native code having its own check for
>>> protection against the X11 error. But, for consistency, shouldn't the
>>> 0,0 be detected and and IAE thrown at a much higher level shared by
>>> all platforms so that no platform can accidentally allow 0,0?
>>> Otherwise we have to make sure that each and every current platform
>>> and each and every future platform port contains these checks to
>>> satisfy the new behavior expectation.
>>>
>>> Apparently, somewhere above the native method there is a check that
>>> converts OOME to IAE - is that in shared code or in the X11-specific
>>> code?
>> It is not a direct conversion from OOME to IAE. Basically, the Java will
>> try to create a accelerated surface and if it cannot, it creates a
>> backup BufferedImage via createCompatibleImage() which calls
>> createCompatibleWritableRaster() and that function has a check for 0
>> width,height which throws IAE.
>>
>> Code wise flow:
>> VolatileSurfaceManager.initialize() will check for accelerated surface
>> via initAcceleratedSurface() which goes to different pipeline for
>> different platforms.
>>
>> In windows, D3DVolatileSurfaceManager.java#initAcceleratedSurface() will
>> call D3DSurfaceData.createData() which calls initSurface() which
>> initializes surface by calling "native" initSurfaceNow() which returns
>> false for 0 width.height. D3DSurfaceData throws InvalidPipeException to
>> D3DVolatileSurfaceManager#initAcceleratedSurface()  which marks
>> accelerated surface as null in that case so Java will fall back to
>> BufferedImage as explained above.
>>
>> In mac, CGLVolatileSurfaceManager.jaav#initAcceleratedSurface() will get
>> OOM from CGlSurfaceData.createData() which calls native initFBObject()
>> which returns false
>>
>> In linux, native was not throwing any issue even though it does not
>> utilise 0 width,height so Java still assumes it is working with
>> accelerated surface so will not try to create backup BufferedImage
>> surface so cannot throw IAE.
>> My fix will let native throw OOM to
>> XRVolatileSurfaceManager.java#initAcceleratedSurface() so that it knows
>> it fails to create accelerated surface and has to fall back to
>> BufferedImage surface and then the IAE will be thrown from
>> createCompatibleWritableRaster()
>>
>>
>> If you think it's ok, we can catch 0 width,height in SunVolatileImage
>> constructor before it calls VolatileSurfacemaanger. initialize() so that
>> it gets trapped  at higher level? Please advise.
>>
>> Regards
>> Prasanta
>>
>>>
>>>             ...jim
>>>
>>> On 11/30/15 9:58 PM, prasanta sadhukhan wrote:
>>>> Modified the testcase to "fail" if IAE is not thrown
>>>> http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.01
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 11/30/2015 2:13 PM, prasanta sadhukhan wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review a fix for jdk9
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8140530
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.00/
>>>>>
>>>>> The issue was creating a volatileImage with 0 width, height does not
>>>>> result in IllegalArgumentException.
>>>>> But, when we try to create a non-volatile Image via
>>>>> GraphicsConfiguration.createCompatibleImage(0,0) or a
>>>>> BufferedImage(0,0,imagetype) it results in IAE.
>>>>> So, to maintain consistency across all image w.r.t 0 width,height,
>>>>> createVolatileImage() should also throw IAE.
>>>>>
>>>>> In windows, creating a volatileImage with 0 width,height resulted in
>>>>> IAE but in linux it does not.
>>>>>
>>>>> This is because XCreatePixmap() generate BadValue unless width,height
>>>>> is nonzero but the error handler does not catch it.
>>>>> https://tronche.com/gui/x/xlib/pixmap-and-cursor/XCreatePixmap.html
>>>>> [The width and height arguments must be nonzero, or a *BadValue* 
>>>>> error
>>>>> results.]
>>>>>
>>>>> I have added a check to prevent zero width,height to be used for
>>>>> XCreatePixmap() and also throw OOME so to ask Java to throw IAE.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>
>>



From james.graham at oracle.com  Fri Dec  4 07:09:46 2015
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 3 Dec 2015 23:09:46 -0800
Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8140530, ,
 Creating a VolatileImage with size 0,
 0 results in no longer working g2d.drawStri
In-Reply-To: <5661300B.8080001@oracle.com>
References: <565C0C1D.3080408@oracle.com> <565D3720.8060009@oracle.com>
	<565F41A3.3050309@oracle.com> <565FECBA.9090604@oracle.com>
	<5660E934.1060606@oracle.com> <5661300B.8080001@oracle.com>
Message-ID: <56613C3A.6030105@oracle.com>

+1

		...jim

On 12/3/15 10:17 PM, prasanta sadhukhan wrote:
> ok. Thanks Jim .
> Please review the modified webrev
> http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.02/
>
> Regards
> Prasanta
> On 12/4/2015 6:45 AM, Jim Graham wrote:
>> I think it makes sense to catch it at a higher level, but also to
>> throw some type of exception from the X11 code as you do now because
>> regardless of our higher level policy, the X11 implementation function
>> can never succeed there...
>>
>> So, my preference would be to keep the existing pieces of this fix
>> that you already have and to add an explicit check and throw IAE to
>> SunVolatileImage for completeness and guaranteed consistency...
>>
>>             ...jim
>>
>> On 12/2/15 11:18 PM, prasanta sadhukhan wrote:
>>> Hi Jim,
>>>
>>> On 12/3/2015 12:38 AM, Jim Graham wrote:
>>>> Hi Prasanta,
>>>>
>>>> (On a practical note, in the HTML version of your message, the text
>>>> said "webrev.01", but the link in the href pointed to "webrev.00" so I
>>>> sat there wondering why the changes you noted weren't there until I
>>>> realized that I was still looking at webrev.00 and had to manually
>>>> enter webrev.01 in the browser to see the new code...)
>>>>
>>>> Have you run your new test on all platforms to make sure that it
>>>> succeeds (by throwing IAE) on all currently supported/tested platorms?
>>>>
>>> IAE was already been thrown for windows and mac. It was not working for
>>> linux only.
>>>> It seems, from the comment, that one issue is that X11 has a special
>>>> need in that if we make it through to the native code with 0,0
>>>> arguments and attempt to create a pixmap of 0,0 then we get an X11
>>>> error so I'm OK with the native code having its own check for
>>>> protection against the X11 error. But, for consistency, shouldn't the
>>>> 0,0 be detected and and IAE thrown at a much higher level shared by
>>>> all platforms so that no platform can accidentally allow 0,0?
>>>> Otherwise we have to make sure that each and every current platform
>>>> and each and every future platform port contains these checks to
>>>> satisfy the new behavior expectation.
>>>>
>>>> Apparently, somewhere above the native method there is a check that
>>>> converts OOME to IAE - is that in shared code or in the X11-specific
>>>> code?
>>> It is not a direct conversion from OOME to IAE. Basically, the Java will
>>> try to create a accelerated surface and if it cannot, it creates a
>>> backup BufferedImage via createCompatibleImage() which calls
>>> createCompatibleWritableRaster() and that function has a check for 0
>>> width,height which throws IAE.
>>>
>>> Code wise flow:
>>> VolatileSurfaceManager.initialize() will check for accelerated surface
>>> via initAcceleratedSurface() which goes to different pipeline for
>>> different platforms.
>>>
>>> In windows, D3DVolatileSurfaceManager.java#initAcceleratedSurface() will
>>> call D3DSurfaceData.createData() which calls initSurface() which
>>> initializes surface by calling "native" initSurfaceNow() which returns
>>> false for 0 width.height. D3DSurfaceData throws InvalidPipeException to
>>> D3DVolatileSurfaceManager#initAcceleratedSurface()  which marks
>>> accelerated surface as null in that case so Java will fall back to
>>> BufferedImage as explained above.
>>>
>>> In mac, CGLVolatileSurfaceManager.jaav#initAcceleratedSurface() will get
>>> OOM from CGlSurfaceData.createData() which calls native initFBObject()
>>> which returns false
>>>
>>> In linux, native was not throwing any issue even though it does not
>>> utilise 0 width,height so Java still assumes it is working with
>>> accelerated surface so will not try to create backup BufferedImage
>>> surface so cannot throw IAE.
>>> My fix will let native throw OOM to
>>> XRVolatileSurfaceManager.java#initAcceleratedSurface() so that it knows
>>> it fails to create accelerated surface and has to fall back to
>>> BufferedImage surface and then the IAE will be thrown from
>>> createCompatibleWritableRaster()
>>>
>>>
>>> If you think it's ok, we can catch 0 width,height in SunVolatileImage
>>> constructor before it calls VolatileSurfacemaanger. initialize() so that
>>> it gets trapped  at higher level? Please advise.
>>>
>>> Regards
>>> Prasanta
>>>
>>>>
>>>>             ...jim
>>>>
>>>> On 11/30/15 9:58 PM, prasanta sadhukhan wrote:
>>>>> Modified the testcase to "fail" if IAE is not thrown
>>>>> http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.01
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 11/30/2015 2:13 PM, prasanta sadhukhan wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Please review a fix for jdk9
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8140530
>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.00/
>>>>>>
>>>>>> The issue was creating a volatileImage with 0 width, height does not
>>>>>> result in IllegalArgumentException.
>>>>>> But, when we try to create a non-volatile Image via
>>>>>> GraphicsConfiguration.createCompatibleImage(0,0) or a
>>>>>> BufferedImage(0,0,imagetype) it results in IAE.
>>>>>> So, to maintain consistency across all image w.r.t 0 width,height,
>>>>>> createVolatileImage() should also throw IAE.
>>>>>>
>>>>>> In windows, creating a volatileImage with 0 width,height resulted in
>>>>>> IAE but in linux it does not.
>>>>>>
>>>>>> This is because XCreatePixmap() generate BadValue unless width,height
>>>>>> is nonzero but the error handler does not catch it.
>>>>>> https://tronche.com/gui/x/xlib/pixmap-and-cursor/XCreatePixmap.html
>>>>>> [The width and height arguments must be nonzero, or a *BadValue*
>>>>>> error
>>>>>> results.]
>>>>>>
>>>>>> I have added a check to prevent zero width,height to be used for
>>>>>> XCreatePixmap() and also throw OOME so to ask Java to throw IAE.
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>
>>>
>


From Sergey.Bylokhov at oracle.com  Fri Dec  4 09:00:00 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 4 Dec 2015 14:30:00 +0530
Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8140530, ,
 Creating a VolatileImage with size 0,
 0 results in no longer working g2d.drawStri
In-Reply-To: <56613C3A.6030105@oracle.com>
References: <565C0C1D.3080408@oracle.com> <565D3720.8060009@oracle.com>
	<565F41A3.3050309@oracle.com> <565FECBA.9090604@oracle.com>
	<5660E934.1060606@oracle.com> <5661300B.8080001@oracle.com>
	<56613C3A.6030105@oracle.com>
Message-ID: <56615610.4030101@oracle.com>

Looks fine to me to.
I guess that the native check still necessary in case we create a native 
surface as a cache for a BufferedImage.

On 04.12.15 12:39, Jim Graham wrote:
> +1
>
>          ...jim
>
> On 12/3/15 10:17 PM, prasanta sadhukhan wrote:
>> ok. Thanks Jim .
>> Please review the modified webrev
>> http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.02/
>>
>> Regards
>> Prasanta
>> On 12/4/2015 6:45 AM, Jim Graham wrote:
>>> I think it makes sense to catch it at a higher level, but also to
>>> throw some type of exception from the X11 code as you do now because
>>> regardless of our higher level policy, the X11 implementation function
>>> can never succeed there...
>>>
>>> So, my preference would be to keep the existing pieces of this fix
>>> that you already have and to add an explicit check and throw IAE to
>>> SunVolatileImage for completeness and guaranteed consistency...
>>>
>>>             ...jim
>>>
>>> On 12/2/15 11:18 PM, prasanta sadhukhan wrote:
>>>> Hi Jim,
>>>>
>>>> On 12/3/2015 12:38 AM, Jim Graham wrote:
>>>>> Hi Prasanta,
>>>>>
>>>>> (On a practical note, in the HTML version of your message, the text
>>>>> said "webrev.01", but the link in the href pointed to "webrev.00" so I
>>>>> sat there wondering why the changes you noted weren't there until I
>>>>> realized that I was still looking at webrev.00 and had to manually
>>>>> enter webrev.01 in the browser to see the new code...)
>>>>>
>>>>> Have you run your new test on all platforms to make sure that it
>>>>> succeeds (by throwing IAE) on all currently supported/tested platorms?
>>>>>
>>>> IAE was already been thrown for windows and mac. It was not working for
>>>> linux only.
>>>>> It seems, from the comment, that one issue is that X11 has a special
>>>>> need in that if we make it through to the native code with 0,0
>>>>> arguments and attempt to create a pixmap of 0,0 then we get an X11
>>>>> error so I'm OK with the native code having its own check for
>>>>> protection against the X11 error. But, for consistency, shouldn't the
>>>>> 0,0 be detected and and IAE thrown at a much higher level shared by
>>>>> all platforms so that no platform can accidentally allow 0,0?
>>>>> Otherwise we have to make sure that each and every current platform
>>>>> and each and every future platform port contains these checks to
>>>>> satisfy the new behavior expectation.
>>>>>
>>>>> Apparently, somewhere above the native method there is a check that
>>>>> converts OOME to IAE - is that in shared code or in the X11-specific
>>>>> code?
>>>> It is not a direct conversion from OOME to IAE. Basically, the Java
>>>> will
>>>> try to create a accelerated surface and if it cannot, it creates a
>>>> backup BufferedImage via createCompatibleImage() which calls
>>>> createCompatibleWritableRaster() and that function has a check for 0
>>>> width,height which throws IAE.
>>>>
>>>> Code wise flow:
>>>> VolatileSurfaceManager.initialize() will check for accelerated surface
>>>> via initAcceleratedSurface() which goes to different pipeline for
>>>> different platforms.
>>>>
>>>> In windows, D3DVolatileSurfaceManager.java#initAcceleratedSurface()
>>>> will
>>>> call D3DSurfaceData.createData() which calls initSurface() which
>>>> initializes surface by calling "native" initSurfaceNow() which returns
>>>> false for 0 width.height. D3DSurfaceData throws InvalidPipeException to
>>>> D3DVolatileSurfaceManager#initAcceleratedSurface()  which marks
>>>> accelerated surface as null in that case so Java will fall back to
>>>> BufferedImage as explained above.
>>>>
>>>> In mac, CGLVolatileSurfaceManager.jaav#initAcceleratedSurface() will
>>>> get
>>>> OOM from CGlSurfaceData.createData() which calls native initFBObject()
>>>> which returns false
>>>>
>>>> In linux, native was not throwing any issue even though it does not
>>>> utilise 0 width,height so Java still assumes it is working with
>>>> accelerated surface so will not try to create backup BufferedImage
>>>> surface so cannot throw IAE.
>>>> My fix will let native throw OOM to
>>>> XRVolatileSurfaceManager.java#initAcceleratedSurface() so that it knows
>>>> it fails to create accelerated surface and has to fall back to
>>>> BufferedImage surface and then the IAE will be thrown from
>>>> createCompatibleWritableRaster()
>>>>
>>>>
>>>> If you think it's ok, we can catch 0 width,height in SunVolatileImage
>>>> constructor before it calls VolatileSurfacemaanger. initialize() so
>>>> that
>>>> it gets trapped  at higher level? Please advise.
>>>>
>>>> Regards
>>>> Prasanta
>>>>
>>>>>
>>>>>             ...jim
>>>>>
>>>>> On 11/30/15 9:58 PM, prasanta sadhukhan wrote:
>>>>>> Modified the testcase to "fail" if IAE is not thrown
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.01
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 11/30/2015 2:13 PM, prasanta sadhukhan wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Please review a fix for jdk9
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8140530
>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.00/
>>>>>>>
>>>>>>> The issue was creating a volatileImage with 0 width, height does not
>>>>>>> result in IllegalArgumentException.
>>>>>>> But, when we try to create a non-volatile Image via
>>>>>>> GraphicsConfiguration.createCompatibleImage(0,0) or a
>>>>>>> BufferedImage(0,0,imagetype) it results in IAE.
>>>>>>> So, to maintain consistency across all image w.r.t 0 width,height,
>>>>>>> createVolatileImage() should also throw IAE.
>>>>>>>
>>>>>>> In windows, creating a volatileImage with 0 width,height resulted in
>>>>>>> IAE but in linux it does not.
>>>>>>>
>>>>>>> This is because XCreatePixmap() generate BadValue unless
>>>>>>> width,height
>>>>>>> is nonzero but the error handler does not catch it.
>>>>>>> https://tronche.com/gui/x/xlib/pixmap-and-cursor/XCreatePixmap.html
>>>>>>> [The width and height arguments must be nonzero, or a *BadValue*
>>>>>>> error
>>>>>>> results.]
>>>>>>>
>>>>>>> I have added a check to prevent zero width,height to be used for
>>>>>>> XCreatePixmap() and also throw OOME so to ask Java to throw IAE.
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>
>>>>
>>


-- 
Best regards, Sergey.


From brian.burkhalter at oracle.com  Fri Dec  4 16:30:49 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 4 Dec 2015 08:30:49 -0800
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8144627: Problem list
	WriteAfterAbort.java
In-Reply-To: <56610B6E.20801@oracle.com>
References: <5660AF81.6090302@oracle.com> <5660AFD6.5030301@oracle.com>
	<5660B093.6090809@oracle.com> <56610B6E.20801@oracle.com>
Message-ID: <075EE50D-17FD-4EFF-AD81-FA1C72ADBF72@oracle.com>

Indeed that is a good thing! :-)

Brian

On Dec 3, 2015, at 7:41 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> ps: I am glad that my test is written in a style that allowed to find a bug in a new plug-in.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151204/356aa0d1/attachment.html>

From bourges.laurent at gmail.com  Fri Dec  4 16:33:59 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 4 Dec 2015 17:33:59 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144718: Pisces / Marlin Strokers may generate
 invalid curves with huge coordinates and round joins
Message-ID: <CAKjRUT6U8+DWi8DQuWuRwQFoKVMwR8hpHFD36isDxDcw-6F-Dw@mail.gmail.com>

Hi,

Please review this webrev  fixing the Stroker bug in both Pisces & Marlin
(same changes):
bug: https://bugs.openjdk.java.net/browse/JDK-8144718
webrev: http://cr.openjdk.java.net/~lbourges/marlin/Stroker-8144718.0/

As this bug is very difficult to reproduce (artefacts), I just provide a
simple test class that reproduces the issue.

Regards,
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151204/f7cfdefa/attachment.html>

From philip.race at oracle.com  Fri Dec  4 21:40:17 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 04 Dec 2015 13:40:17 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8137106: EUDC (End User Defined Characters)
 are not displayed on Windows with Java 8u60+
Message-ID: <56620841.1010909@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8137106
http://cr.openjdk.java.net/~prr/8137106/index.html

See the bug report for a long evaluation but here is the short version.
In order to prevent recursive creation of the FontManager we need to
have loading the construction of the TrueTypeFont representing the EUDC
font avoid referencing the FontManager. This is done by locally opening
and closing the font file in just that case.

This fix is designed to be low-risk as it needs backporting.

A test for this is not practical as it requires a user to install an 
EUDC font which
requires special steps different than installing a normal font.
Manual verification will be required.

-phil.


From brian.burkhalter at oracle.com  Fri Dec  4 22:27:26 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 4 Dec 2015 14:27:26 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8144245: [PIT]
	javax/imageio/plugins/shared/WriteAfterAbort.java
Message-ID: <60DCC72E-224E-4B81-BB2E-C1F2ED1E1338@oracle.com>

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8144245
Patch:	http://cr.openjdk.java.net/~bpb/8144245/webrev.00/

For the principal issue, the stream position was not being reset when the write was aborted to either the header position or to the position of the current IFD, as appropriate. As part of the investigation, a missing check in TIFFIFD was discovered. Also, a few occurrences in TIFFImageWriter of a NullPointerException being thrown where an IllegalArgumentException was expected were corrected. Lastly, the test was slightly modified to iterate over all registered writers and fail at the end instead of bailing out on the first failure.

Thanks,

Brian

From philip.race at oracle.com  Fri Dec  4 22:43:16 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 04 Dec 2015 14:43:16 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144654: Improve Marlin logging
In-Reply-To: <CAKjRUT51G2n6=U1uJx+_H_ZqYjkbWKp4obwktWxEzyFZOW-zwA@mail.gmail.com>
References: <CAKjRUT51G2n6=U1uJx+_H_ZqYjkbWKp4obwktWxEzyFZOW-zwA@mail.gmail.com>
Message-ID: <56621704.2010302@oracle.com>


  139     public static boolean isEnableLogs() {
  140         return getBoolean("sun.java2d.renderer.log", "false");
  141     }

All of these begin with sun.java2d.renderer but they are all marlin 
specific.
I guess it is OK though if we expect that ultimately marlin is the only 
renderer.

"isEnable" does not read well but I know that the same pattern is used for
everything so I don't have a firm objection although the "is" seems likeit
is could be removed in most cases. Some may need a "do" adding

You have deleted getCallerInfo so probably you can close
https://bugs.openjdk.java.net/browse/JDK-8144530 as a dup of this bug.

-phil.

On 12/03/2015 02:17 PM, Laurent Bourg?s wrote:
> https://bugs.openjdk.java.net/browse/JDK-8144654
>
> Please review this webrev that fixes logging issues in Marlin:
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144654.0/ 
> <http://cr.openjdk.java.net/%7Elbourges/marlin/marlin-8144654.0/>
>
> Changes:
> - Byte/Float/Int/ArrayCache: use logInfo instead of System.out
> - MarlinConst: enableLogs uses MarlinProperties.isEnableLogs() and 
> restore potential doMonitors / doChecks flags
> - MarlinProperties: added isEnableLogs()
> - MarlinUtils: use PlatformLogger instead of Logger and removed 
> getCallerInfos()
> - RendererContext: remove all MarlinUtils.getCallerInfos()
>
> Best regards,
> Laurent Bourg?s

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151204/c90a4f20/attachment.html>

From philip.race at oracle.com  Fri Dec  4 22:45:33 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 04 Dec 2015 14:45:33 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144630: Use PrivilegedAction to create
 Thread in Marlin RendererStats
In-Reply-To: <CAKjRUT7J_YS6sUQFhQ96WVVfsZ5-RgnJQiJiLj8fgMYkNk4oWw@mail.gmail.com>
References: <CAKjRUT7J_YS6sUQFhQ96WVVfsZ5-RgnJQiJiLj8fgMYkNk4oWw@mail.gmail.com>
Message-ID: <5662178D.6050300@oracle.com>

Looks good. BTW the JBS bug needs a "noreg-other" label (or similar)
for all bugs that do not need a regression test.

-phil.

On 12/03/2015 01:37 PM, Laurent Bourg?s wrote:
> https://bugs.openjdk.java.net/browse/JDK-8144630
>
> Please review this simple webrev that fixes the Thread creation in 
> RendererStats:
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144630.0/ 
> <http://cr.openjdk.java.net/%7Elbourges/marlin/marlin-8144630.0/>
>
> Regards,
> Laurent Bourg?s



From philip.race at oracle.com  Fri Dec  4 22:47:13 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 04 Dec 2015 14:47:13 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144445: Maximum size checking in Marlin
 ArrayCache utility methods is not optimal
In-Reply-To: <CAKjRUT7=puzVxKiqEGoCae_QCcw6Nu-HBZa6LvmB=Uqcf0mcyA@mail.gmail.com>
References: <CAKjRUT7=puzVxKiqEGoCae_QCcw6Nu-HBZa6LvmB=Uqcf0mcyA@mail.gmail.com>
Message-ID: <566217F1.3080202@oracle.com>

Looks good to me.

-phil.

On 12/03/2015 01:23 PM, Laurent Bourg?s wrote:
>
> https://bugs.openjdk.java.net/browse/JDK-8144445
>
> Please review that webrev that improves overflow checks in ArrayCache:
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144445.0/ 
> <http://cr.openjdk.java.net/%7Elbourges/marlin/marlin-8144445.0/>
>
> Changes
> - check 2Gb overflow in both getNewSize() and getNewLargeSize()
> - check negative size / needSize (potential integer math overflow)
> - fixed Stroker to use substraction and avoid integer overflow
> - added ArrayCacheSizeTest class which now passes in jtreg
>
> Jim's previous comments:
> The change looks fine.
> Are the long modifiers (12L, 1L, etc) really needed on the shift 
> parameters given that the first operand (needSize) is already a long?
>
>  202             size = ((needSize >> 12L) + 1L) << 12L;
>
> I prefer keeping the long modifiers to be more explicit.
>
> Regards,
> Laurent



From james.graham at oracle.com  Fri Dec  4 22:52:08 2015
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 4 Dec 2015 14:52:08 -0800
Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8140530, ,
 Creating a VolatileImage with size 0,
 0 results in no longer working g2d.drawStri
In-Reply-To: <56615610.4030101@oracle.com>
References: <565C0C1D.3080408@oracle.com> <565D3720.8060009@oracle.com>
	<565F41A3.3050309@oracle.com> <565FECBA.9090604@oracle.com>
	<5660E934.1060606@oracle.com> <5661300B.8080001@oracle.com>
	<56613C3A.6030105@oracle.com> <56615610.4030101@oracle.com>
Message-ID: <56621918.5060308@oracle.com>

On 12/4/15 1:00 AM, Sergey Bylokhov wrote:
> Looks fine to me to.
> I guess that the native check still necessary in case we create a native
> surface as a cache for a BufferedImage.

Or in case we want to relax the general API restriction later, it keeps 
us from ending up with a hard-to-diagnose bug on the X11 pipeline. We'll 
find out right away that we need an alternate solution for X11...

			...jim

> On 04.12.15 12:39, Jim Graham wrote:
>> +1
>>
>>          ...jim
>>
>> On 12/3/15 10:17 PM, prasanta sadhukhan wrote:
>>> ok. Thanks Jim .
>>> Please review the modified webrev
>>> http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.02/
>>>
>>> Regards
>>> Prasanta
>>> On 12/4/2015 6:45 AM, Jim Graham wrote:
>>>> I think it makes sense to catch it at a higher level, but also to
>>>> throw some type of exception from the X11 code as you do now because
>>>> regardless of our higher level policy, the X11 implementation function
>>>> can never succeed there...
>>>>
>>>> So, my preference would be to keep the existing pieces of this fix
>>>> that you already have and to add an explicit check and throw IAE to
>>>> SunVolatileImage for completeness and guaranteed consistency...
>>>>
>>>>             ...jim
>>>>
>>>> On 12/2/15 11:18 PM, prasanta sadhukhan wrote:
>>>>> Hi Jim,
>>>>>
>>>>> On 12/3/2015 12:38 AM, Jim Graham wrote:
>>>>>> Hi Prasanta,
>>>>>>
>>>>>> (On a practical note, in the HTML version of your message, the text
>>>>>> said "webrev.01", but the link in the href pointed to "webrev.00"
>>>>>> so I
>>>>>> sat there wondering why the changes you noted weren't there until I
>>>>>> realized that I was still looking at webrev.00 and had to manually
>>>>>> enter webrev.01 in the browser to see the new code...)
>>>>>>
>>>>>> Have you run your new test on all platforms to make sure that it
>>>>>> succeeds (by throwing IAE) on all currently supported/tested
>>>>>> platorms?
>>>>>>
>>>>> IAE was already been thrown for windows and mac. It was not working
>>>>> for
>>>>> linux only.
>>>>>> It seems, from the comment, that one issue is that X11 has a special
>>>>>> need in that if we make it through to the native code with 0,0
>>>>>> arguments and attempt to create a pixmap of 0,0 then we get an X11
>>>>>> error so I'm OK with the native code having its own check for
>>>>>> protection against the X11 error. But, for consistency, shouldn't the
>>>>>> 0,0 be detected and and IAE thrown at a much higher level shared by
>>>>>> all platforms so that no platform can accidentally allow 0,0?
>>>>>> Otherwise we have to make sure that each and every current platform
>>>>>> and each and every future platform port contains these checks to
>>>>>> satisfy the new behavior expectation.
>>>>>>
>>>>>> Apparently, somewhere above the native method there is a check that
>>>>>> converts OOME to IAE - is that in shared code or in the X11-specific
>>>>>> code?
>>>>> It is not a direct conversion from OOME to IAE. Basically, the Java
>>>>> will
>>>>> try to create a accelerated surface and if it cannot, it creates a
>>>>> backup BufferedImage via createCompatibleImage() which calls
>>>>> createCompatibleWritableRaster() and that function has a check for 0
>>>>> width,height which throws IAE.
>>>>>
>>>>> Code wise flow:
>>>>> VolatileSurfaceManager.initialize() will check for accelerated surface
>>>>> via initAcceleratedSurface() which goes to different pipeline for
>>>>> different platforms.
>>>>>
>>>>> In windows, D3DVolatileSurfaceManager.java#initAcceleratedSurface()
>>>>> will
>>>>> call D3DSurfaceData.createData() which calls initSurface() which
>>>>> initializes surface by calling "native" initSurfaceNow() which returns
>>>>> false for 0 width.height. D3DSurfaceData throws
>>>>> InvalidPipeException to
>>>>> D3DVolatileSurfaceManager#initAcceleratedSurface()  which marks
>>>>> accelerated surface as null in that case so Java will fall back to
>>>>> BufferedImage as explained above.
>>>>>
>>>>> In mac, CGLVolatileSurfaceManager.jaav#initAcceleratedSurface() will
>>>>> get
>>>>> OOM from CGlSurfaceData.createData() which calls native initFBObject()
>>>>> which returns false
>>>>>
>>>>> In linux, native was not throwing any issue even though it does not
>>>>> utilise 0 width,height so Java still assumes it is working with
>>>>> accelerated surface so will not try to create backup BufferedImage
>>>>> surface so cannot throw IAE.
>>>>> My fix will let native throw OOM to
>>>>> XRVolatileSurfaceManager.java#initAcceleratedSurface() so that it
>>>>> knows
>>>>> it fails to create accelerated surface and has to fall back to
>>>>> BufferedImage surface and then the IAE will be thrown from
>>>>> createCompatibleWritableRaster()
>>>>>
>>>>>
>>>>> If you think it's ok, we can catch 0 width,height in SunVolatileImage
>>>>> constructor before it calls VolatileSurfacemaanger. initialize() so
>>>>> that
>>>>> it gets trapped  at higher level? Please advise.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>>
>>>>>>
>>>>>>             ...jim
>>>>>>
>>>>>> On 11/30/15 9:58 PM, prasanta sadhukhan wrote:
>>>>>>> Modified the testcase to "fail" if IAE is not thrown
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.01
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 11/30/2015 2:13 PM, prasanta sadhukhan wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Please review a fix for jdk9
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8140530
>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.00/
>>>>>>>>
>>>>>>>> The issue was creating a volatileImage with 0 width, height does
>>>>>>>> not
>>>>>>>> result in IllegalArgumentException.
>>>>>>>> But, when we try to create a non-volatile Image via
>>>>>>>> GraphicsConfiguration.createCompatibleImage(0,0) or a
>>>>>>>> BufferedImage(0,0,imagetype) it results in IAE.
>>>>>>>> So, to maintain consistency across all image w.r.t 0 width,height,
>>>>>>>> createVolatileImage() should also throw IAE.
>>>>>>>>
>>>>>>>> In windows, creating a volatileImage with 0 width,height
>>>>>>>> resulted in
>>>>>>>> IAE but in linux it does not.
>>>>>>>>
>>>>>>>> This is because XCreatePixmap() generate BadValue unless
>>>>>>>> width,height
>>>>>>>> is nonzero but the error handler does not catch it.
>>>>>>>> https://tronche.com/gui/x/xlib/pixmap-and-cursor/XCreatePixmap.html
>>>>>>>> [The width and height arguments must be nonzero, or a *BadValue*
>>>>>>>> error
>>>>>>>> results.]
>>>>>>>>
>>>>>>>> I have added a check to prevent zero width,height to be used for
>>>>>>>> XCreatePixmap() and also throw OOME so to ask Java to throw IAE.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>
>>>>>
>>>
>
>


From james.graham at oracle.com  Fri Dec  4 22:55:00 2015
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 4 Dec 2015 14:55:00 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
Message-ID: <566219C4.303@oracle.com>

Looks good to me.  Are jigsaw issues good Phil?

			...jim

On 12/3/15 12:58 PM, Laurent Bourg?s wrote:
> Phil,
>
>     If you were to run this on a jigsaw EA build it would fail due to
>     accessing
>     sun.java2d.pipe.RenderingEngine. I know this is "pre-existing" but
>     jigsaw is coming ...
>
>
> You're right, sorry !
>
> Here is a new webrev:
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.1/
>
> Changes:
> - set System property "sun.java2d.renderer.verbose" to true (to get the
> renderer in use)
> - removed any RenderingEngine usage
>
> Laurent


From philip.race at oracle.com  Fri Dec  4 22:55:57 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 04 Dec 2015 14:55:57 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8144245: [PIT]
	javax/imageio/plugins/shared/WriteAfterAbort.java
In-Reply-To: <60DCC72E-224E-4B81-BB2E-C1F2ED1E1338@oracle.com>
References: <60DCC72E-224E-4B81-BB2E-C1F2ED1E1338@oracle.com>
Message-ID: <566219FD.203@oracle.com>

looks good.

-phil.

On 12/04/2015 02:27 PM, Brian Burkhalter wrote:
> Please review at your convenience.
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8144245
> Patch:	http://cr.openjdk.java.net/~bpb/8144245/webrev.00/
>
> For the principal issue, the stream position was not being reset when the write was aborted to either the header position or to the position of the current IFD, as appropriate. As part of the investigation, a missing check in TIFFIFD was discovered. Also, a few occurrences in TIFFImageWriter of a NullPointerException being thrown where an IllegalArgumentException was expected were corrected. Lastly, the test was slightly modified to iterate over all registered writers and fail at the end instead of bailing out on the first failure.
>
> Thanks,
>
> Brian



From philip.race at oracle.com  Fri Dec  4 22:57:12 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 04 Dec 2015 14:57:12 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <566219C4.303@oracle.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
	<566219C4.303@oracle.com>
Message-ID: <56621A48.7020406@oracle.com>

Looks good.

-phil.

On 12/04/2015 02:55 PM, Jim Graham wrote:
> Looks good to me.  Are jigsaw issues good Phil?
>
>             ...jim
>
> On 12/3/15 12:58 PM, Laurent Bourg?s wrote:
>> Phil,
>>
>>     If you were to run this on a jigsaw EA build it would fail due to
>>     accessing
>>     sun.java2d.pipe.RenderingEngine. I know this is "pre-existing" but
>>     jigsaw is coming ...
>>
>>
>> You're right, sorry !
>>
>> Here is a new webrev:
>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.1/
>>
>> Changes:
>> - set System property "sun.java2d.renderer.verbose" to true (to get the
>> renderer in use)
>> - removed any RenderingEngine usage
>>
>> Laurent



From james.graham at oracle.com  Fri Dec  4 23:00:16 2015
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 4 Dec 2015 15:00:16 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144718: Pisces / Marlin Strokers may
 generate invalid curves with huge coordinates and round joins
In-Reply-To: <CAKjRUT6U8+DWi8DQuWuRwQFoKVMwR8hpHFD36isDxDcw-6F-Dw@mail.gmail.com>
References: <CAKjRUT6U8+DWi8DQuWuRwQFoKVMwR8hpHFD36isDxDcw-6F-Dw@mail.gmail.com>
Message-ID: <56621B00.9090309@oracle.com>

I'd make the test >= 0.5 since 0.5 generates a flat curve as well.

And it couldn't hurt to mention that we are worried about round off 
error since someone coming along might wonder why we're worried that a 
cos() is > 1:

// check round off errors producing cos(ext) > 1 and a NaN below
// cos(ext) == 1 implies colinear segments and an empty join anyway

		...jim

On 12/4/15 8:33 AM, Laurent Bourg?s wrote:
> Hi,
>
> Please review this webrev  fixing the Stroker bug in both Pisces &
> Marlin (same changes):
> bug: https://bugs.openjdk.java.net/browse/JDK-8144718
> webrev: http://cr.openjdk.java.net/~lbourges/marlin/Stroker-8144718.0/
>
> As this bug is very difficult to reproduce (artefacts), I just provide a
> simple test class that reproduces the issue.
>
> Regards,
> Laurent Bourg?s


From james.graham at oracle.com  Fri Dec  4 23:05:38 2015
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 4 Dec 2015 15:05:38 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144654: Improve Marlin logging
In-Reply-To: <56621704.2010302@oracle.com>
References: <CAKjRUT51G2n6=U1uJx+_H_ZqYjkbWKp4obwktWxEzyFZOW-zwA@mail.gmail.com>
	<56621704.2010302@oracle.com>
Message-ID: <56621C42.8050807@oracle.com>

Perhaps "isLoggingEnabled()"?

This turns a bunch of constants from having compile-time values to 
run-time values so the javac compiler will no longer be able to compile 
the code out of the classfiles.  On the other hand, the fields are still 
final so the Hotspot compiler should still be able to eliminate the 
associated code at run-time, so hopefully this had no impact on performance?

			...jim

On 12/4/15 2:43 PM, Phil Race wrote:
> 139 public static boolean isEnableLogs() {
> 140 return getBoolean("sun.java2d.renderer.log", "false");
> 141 }
>
> All of these begin with sun.java2d.renderer but they are all marlin
> specific.
> I guess it is OK though if we expect that ultimately marlin is the only
> renderer.
>
> "isEnable" does not read well but I know that the same pattern is used for
> everything so I don't have a firm objection although the "is" seems likeit
> is could be removed in most cases. Some may need a "do" adding
>
> You have deleted getCallerInfo so probably you can close
> https://bugs.openjdk.java.net/browse/JDK-8144530 as a dup of this bug.
>
> -phil.
>
> On 12/03/2015 02:17 PM, Laurent Bourg?s wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8144654
>>
>> Please review this webrev that fixes logging issues in Marlin:
>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144654.0/
>> <http://cr.openjdk.java.net/%7Elbourges/marlin/marlin-8144654.0/>
>>
>> Changes:
>> - Byte/Float/Int/ArrayCache: use logInfo instead of System.out
>> - MarlinConst: enableLogs uses MarlinProperties.isEnableLogs() and
>> restore potential doMonitors / doChecks flags
>> - MarlinProperties: added isEnableLogs()
>> - MarlinUtils: use PlatformLogger instead of Logger and removed
>> getCallerInfos()
>> - RendererContext: remove all MarlinUtils.getCallerInfos()
>>
>> Best regards,
>> Laurent Bourg?s
>


From james.graham at oracle.com  Fri Dec  4 23:07:17 2015
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 4 Dec 2015 15:07:17 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144630: Use PrivilegedAction to create
 Thread in Marlin RendererStats
In-Reply-To: <CAKjRUT7J_YS6sUQFhQ96WVVfsZ5-RgnJQiJiLj8fgMYkNk4oWw@mail.gmail.com>
References: <CAKjRUT7J_YS6sUQFhQ96WVVfsZ5-RgnJQiJiLj8fgMYkNk4oWw@mail.gmail.com>
Message-ID: <56621CA5.2080806@oracle.com>

Looks good...

			...jim

On 12/3/15 1:37 PM, Laurent Bourg?s wrote:
> https://bugs.openjdk.java.net/browse/JDK-8144630
>
> Please review this simple webrev that fixes the Thread creation in
> RendererStats:
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144630.0/
>
> Regards,
> Laurent Bourg?s


From james.graham at oracle.com  Fri Dec  4 23:13:30 2015
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 4 Dec 2015 15:13:30 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144445: Maximum size checking in Marlin
 ArrayCache utility methods is not optimal
In-Reply-To: <CAKjRUT7=puzVxKiqEGoCae_QCcw6Nu-HBZa6LvmB=Uqcf0mcyA@mail.gmail.com>
References: <CAKjRUT7=puzVxKiqEGoCae_QCcw6Nu-HBZa6LvmB=Uqcf0mcyA@mail.gmail.com>
Message-ID: <56621E1A.1080602@oracle.com>

ArrayCache.java line 214 - was that supposed to be size or needSize on 
that line?

Stroker.java line 1276 - "numCurves >= curveTypes.length" would also 
work...?

In the test cases that expect an exception, if no exception is thrown 
then you pass the test.  Is that right?

			...jim

On 12/3/15 1:23 PM, Laurent Bourg?s wrote:
>
> https://bugs.openjdk.java.net/browse/JDK-8144445
>
> Please review that webrev that improves overflow checks in ArrayCache:
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144445.0/
>
> Changes
> - check 2Gb overflow in both getNewSize() and getNewLargeSize()
> - check negative size / needSize (potential integer math overflow)
> - fixed Stroker to use substraction and avoid integer overflow
> - added ArrayCacheSizeTest class which now passes in jtreg
>
> Jim's previous comments:
> The change looks fine.
> Are the long modifiers (12L, 1L, etc) really needed on the shift
> parameters given that the first operand (needSize) is already a long?
>
>   202             size = ((needSize >> 12L) + 1L) << 12L;
>
> I prefer keeping the long modifiers to be more explicit.
>
> Regards,
> Laurent


From bourges.laurent at gmail.com  Sat Dec  5 16:13:32 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Sat, 5 Dec 2015 17:13:32 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <56621A48.7020406@oracle.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
	<566219C4.303@oracle.com> <56621A48.7020406@oracle.com>
Message-ID: <CAKjRUT4oA+s2aF11ypkUGfCJLJ8=9V_NpuejrUVfL9cm8UHO0g@mail.gmail.com>

Phil,

2 reviewers approved, so please push it for me !

Laurent

2015-12-04 23:57 GMT+01:00 Phil Race <philip.race at oracle.com>:

> Looks good.
>
> -phil.
>
>
> On 12/04/2015 02:55 PM, Jim Graham wrote:
>
>> Looks good to me.  Are jigsaw issues good Phil?
>>
>>             ...jim
>>
>> On 12/3/15 12:58 PM, Laurent Bourg?s wrote:
>>
>>> Phil,
>>>
>>>     If you were to run this on a jigsaw EA build it would fail due to
>>>     accessing
>>>     sun.java2d.pipe.RenderingEngine. I know this is "pre-existing" but
>>>     jigsaw is coming ...
>>>
>>>
>>> You're right, sorry !
>>>
>>> Here is a new webrev:
>>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.1/
>>>
>>> Changes:
>>> - set System property "sun.java2d.renderer.verbose" to true (to get the
>>> renderer in use)
>>> - removed any RenderingEngine usage
>>>
>>> Laurent
>>>
>>
>


-- 
-- 
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151205/43affb75/attachment.html>

From bourges.laurent at gmail.com  Sat Dec  5 16:13:56 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Sat, 5 Dec 2015 17:13:56 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144630: Use PrivilegedAction to create
 Thread in Marlin RendererStats
In-Reply-To: <56621CA5.2080806@oracle.com>
References: <CAKjRUT7J_YS6sUQFhQ96WVVfsZ5-RgnJQiJiLj8fgMYkNk4oWw@mail.gmail.com>
	<56621CA5.2080806@oracle.com>
Message-ID: <CAKjRUT5NsjyjKYgEAza7J4gYtdr5i-=ZNFz1CMN+GgHPX5y=7g@mail.gmail.com>

Phil,

2 reviewers approved, so please push it for me !

Laurent

2015-12-05 0:07 GMT+01:00 Jim Graham <james.graham at oracle.com>:

> Looks good...
>
>                         ...jim
>
>
> On 12/3/15 1:37 PM, Laurent Bourg?s wrote:
>
>> https://bugs.openjdk.java.net/browse/JDK-8144630
>>
>> Please review this simple webrev that fixes the Thread creation in
>> RendererStats:
>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144630.0/
>>
>> Regards,
>> Laurent Bourg?s
>>
>


-- 
-- 
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151205/970c0fe1/attachment.html>

From bourges.laurent at gmail.com  Sat Dec  5 16:33:28 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Sat, 5 Dec 2015 17:33:28 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144718: Pisces / Marlin Strokers may
 generate invalid curves with huge coordinates and round joins
In-Reply-To: <56621B00.9090309@oracle.com>
References: <CAKjRUT6U8+DWi8DQuWuRwQFoKVMwR8hpHFD36isDxDcw-6F-Dw@mail.gmail.com>
	<56621B00.9090309@oracle.com>
Message-ID: <CAKjRUT7KPBQ+g7aQ1Qsco-FBuxNAT9COKHn+gMsDAyJKmFYC6g@mail.gmail.com>

Jim,

here is the updated webrev:
http://cr.openjdk.java.net/~lbourges/marlin/Stroker-8144718.1/

Changes:
- added the comment you proposed
- Marlin: use precomputed invHalfLineWidth2Sq = 1f / (2f * lineWidth2 *
lineWidth2) for performance
- fix copyright date in Pisces Stroker

Laurent

2015-12-05 0:00 GMT+01:00 Jim Graham <james.graham at oracle.com>:

> I'd make the test >= 0.5 since 0.5 generates a flat curve as well.
>
> And it couldn't hurt to mention that we are worried about round off error
> since someone coming along might wonder why we're worried that a cos() is >
> 1:
>
> // check round off errors producing cos(ext) > 1 and a NaN below
> // cos(ext) == 1 implies colinear segments and an empty join anyway
>
>                 ...jim
>
>
> On 12/4/15 8:33 AM, Laurent Bourg?s wrote:
>
>> Hi,
>>
>> Please review this webrev  fixing the Stroker bug in both Pisces &
>> Marlin (same changes):
>> bug: https://bugs.openjdk.java.net/browse/JDK-8144718
>> webrev: http://cr.openjdk.java.net/~lbourges/marlin/Stroker-8144718.0/
>>
>> As this bug is very difficult to reproduce (artefacts), I just provide a
>> simple test class that reproduces the issue.
>>
>> Regards,
>> Laurent Bourg?s
>>
>


-- 
-- 
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151205/1da1287e/attachment.html>

From bourges.laurent at gmail.com  Sat Dec  5 16:54:18 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Sat, 5 Dec 2015 17:54:18 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144654: Improve Marlin logging
In-Reply-To: <56621C42.8050807@oracle.com>
References: <CAKjRUT51G2n6=U1uJx+_H_ZqYjkbWKp4obwktWxEzyFZOW-zwA@mail.gmail.com>
	<56621704.2010302@oracle.com> <56621C42.8050807@oracle.com>
Message-ID: <CAKjRUT7evVLiTUzVMDYVpJw1Mfevb+gPuBgR3bCm=fwejooZLg@mail.gmail.com>

Phil & Jim,

Here is the updated webrev:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144654.1/

Changes:
- isEnableLogs() renamed to isLoggingEnabled(); I used the convention
"is<MemberName>" even if it is not english !
- restored doMonitors to false (as it reduces the bytecode count for
inlining)

Comments below:

2015-12-05 0:05 GMT+01:00 Jim Graham <james.graham at oracle.com>:

> Perhaps "isLoggingEnabled()"?
>

Fixed.


>
> This turns a bunch of constants from having compile-time values to
> run-time values so the javac compiler will no longer be able to compile the
> code out of the classfiles.  On the other hand, the fields are still final
> so the Hotspot compiler should still be able to eliminate the associated
> code at run-time, so hopefully this had no impact on performance?
>

No

>
>
> On 12/4/15 2:43 PM, Phil Race wrote:
>
>> 139 public static boolean isEnableLogs() {
>> 140 return getBoolean("sun.java2d.renderer.log", "false");
>> 141 }
>>
>> All of these begin with sun.java2d.renderer but they are all marlin
>> specific.
>> I guess it is OK though if we expect that ultimately marlin is the only
>> renderer.
>>
>
I can later rename all Marlin system properties at once to use the prefix
"sun.java2d.marlin" if you prefer (already discussed?).


>
>> "isEnable" does not read well but I know that the same pattern is used for
>> everything so I don't have a firm objection although the "is" seems likeit
>> is could be removed in most cases. Some may need a "do" adding
>>
>
Fixed using Jim's proposal.


>
>> You have deleted getCallerInfo so probably you can close
>> https://bugs.openjdk.java.net/browse/JDK-8144530 as a dup of this bug.
>>
>
Done.

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151205/e759bc61/attachment.html>

From bourges.laurent at gmail.com  Mon Dec  7 10:17:45 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Mon, 7 Dec 2015 11:17:45 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144445: Maximum size checking in Marlin
 ArrayCache utility methods is not optimal
In-Reply-To: <56621E1A.1080602@oracle.com>
References: <CAKjRUT7=puzVxKiqEGoCae_QCcw6Nu-HBZa6LvmB=Uqcf0mcyA@mail.gmail.com>
	<56621E1A.1080602@oracle.com>
Message-ID: <CAKjRUT4B2g+FPZKYHUfXipbBhQiAy9PFxEN2v2zvntb1LmVWGg@mail.gmail.com>

Jim,

Here is an updated webrev:

http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144445.1/

See my comments below:
Le 5 d?c. 2015 00:13, "Jim Graham" <james.graham at oracle.com> a ?crit :

> ArrayCache.java line 214 - was that supposed to be size or needSize on
> that line?
>
 214         if (needSize < 0L || size > Integer.MAX_VALUE) {

I think it is correct:
- check size > MAX_INT to detect integer overflow
- check needSize is negative to detect integer overflow on the needed size:
it is possible in Renderer:

final int edgePtr = _edges.used;
...
final long edgeNewSize = ArrayCache.getNewLargeSize(_edges.length,
                                        edgePtr + _SIZEOF_EDGE_BYTES);

( edgePtr + _SIZEOF_EDGE_BYTES )  is an integer so it can become negative !

I could also check size < 0L if you want but it is only possible if curSize
< 0 (that should never happen) !

If you want, I could add few assertions.


> Stroker.java line 1276 - "numCurves >= curveTypes.length" would also
> work...?
>

Fixed.


>
> In the test cases that expect an exception, if no exception is thrown then
> you pass the test.  Is that right?
>

Fixed.


>
> On 12/3/15 1:23 PM, Laurent Bourg?s wrote:
>
>>
>> https://bugs.openjdk.java.net/browse/JDK-8144445
>>
>> Please review that webrev that improves overflow checks in ArrayCache:
>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144445.0/
>>
>> Changes
>> - check 2Gb overflow in both getNewSize() and getNewLargeSize()
>> - check negative size / needSize (potential integer math overflow)
>> - fixed Stroker to use substraction and avoid integer overflow
>> - added ArrayCacheSizeTest class which now passes in jtreg
>>
>> Jim's previous comments:
>> The change looks fine.
>> Are the long modifiers (12L, 1L, etc) really needed on the shift
>> parameters given that the first operand (needSize) is already a long?
>>
>>   202             size = ((needSize >> 12L) + 1L) << 12L;
>>
>> I prefer keeping the long modifiers to be more explicit.
>>
>> Regards,
>> Laurent
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151207/2a0886f8/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Dec  7 13:20:36 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 7 Dec 2015 16:20:36 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8144245: [PIT]
 javax/imageio/plugins/shared/WriteAfterAbort.java
In-Reply-To: <566219FD.203@oracle.com>
References: <60DCC72E-224E-4B81-BB2E-C1F2ED1E1338@oracle.com>
	<566219FD.203@oracle.com>
Message-ID: <566587A4.80708@oracle.com>

Looks fine.

On 05.12.15 1:55, Phil Race wrote:
> looks good.
>
> -phil.
>
> On 12/04/2015 02:27 PM, Brian Burkhalter wrote:
>> Please review at your convenience.
>>
>> Issue:    https://bugs.openjdk.java.net/browse/JDK-8144245
>> Patch:    http://cr.openjdk.java.net/~bpb/8144245/webrev.00/
>>
>> For the principal issue, the stream position was not being reset when
>> the write was aborted to either the header position or to the position
>> of the current IFD, as appropriate. As part of the investigation, a
>> missing check in TIFFIFD was discovered. Also, a few occurrences in
>> TIFFImageWriter of a NullPointerException being thrown where an
>> IllegalArgumentException was expected were corrected. Lastly, the test
>> was slightly modified to iterate over all registered writers and fail
>> at the end instead of bailing out on the first failure.
>>
>> Thanks,
>>
>> Brian
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Dec  7 15:31:37 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 7 Dec 2015 18:31:37 +0300
Subject: [OpenJDK 2D-Dev] [9] RFR JDK-7160052:
 GlyphVector.setGlyphPosition can throw an exception on valid input
In-Reply-To: <56584305.70605@oracle.com>
References: <56584305.70605@oracle.com>
Message-ID: <5665A659.4030205@oracle.com>

Hi, Prasanta.
Can you please confirm that we properly use clearCaches() in other 
places of StandardGlyphVector.java?

On 27.11.15 14:48, prasanta sadhukhan wrote:
> Hi All,
>
> Please review a fix for jdk9
> Bug: https://bugs.openjdk.java.net/browse/JDK-7160052
> webrev: http://cr.openjdk.java.net/~psadhukhan/7160052/webrev.00/
>
> Issue:
> GlyphVector.setGlyphPosition(int glyphIndex, Point2D
> <imap://Sergey%2EBylokhov%40oracle%2Ecom at stbeehive.oracle.com:993/fetch%3EUID%3E/mailing%20list/2d%3E5454?header=quotebody&part=1.2.2&filename=Point2D.html> newPos)
> can have glyphIndex "equal" to the number of glyphs in this GlyphVector
> so if user tries to call GlyphVector.setGlyphPosition(gv.getNumGlyphs(),
> gv.getGlyphPosition(gv.getNumGlyphs()) it throws IndexOutOfBoundsException
>
> Cause:
> StandardGlyphVector maintains a glyph cache for the glyphs stored in the
> GlyphVector via lbcache = new Shape[glyphs.length];
>
> When GlyphVector.setGlyphPosition() is called, it positions the glyph at
> the specified glyphIndex|||||||||| and tries to clear the mentioned
> glyphIndex position of cache by calling clearCache(glyphIndex)
> But, if we pass the glyphIndex == number of glyphs, then it tries to
> access beyond the cache array resulting in IOB.
>
> Fix:
> Checked if glyphIndex passed as argument is equal to number of glyphs
> then do not try to clear the cache as setGlyphPosition() will anyway
> sets the position after the last glyph.
> Also, added this check as per spec|IndexOutOfBoundsException
> <imap://Sergey%2EBylokhov%40oracle%2Ecom at stbeehive.oracle.com:993/fetch%3EUID%3E/mailing%20list/2d%3E5454?header=quotebody&part=1.2.3&filename=IndexOutOfBoundsException.html>|
> - if |glyphIndex| is less than 0 or greater than the number of glyphs in
> this |GlyphVector
> |
> Regards
> Prasanta
>
> ||||


-- 
Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Mon Dec  7 15:43:59 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Mon, 7 Dec 2015 21:13:59 +0530
Subject: [OpenJDK 2D-Dev] [9] RFR JDK-7160052:
 GlyphVector.setGlyphPosition can throw an exception on valid input
In-Reply-To: <5665A659.4030205@oracle.com>
References: <56584305.70605@oracle.com> <5665A659.4030205@oracle.com>
Message-ID: <5665A93F.4020406@oracle.com>

Hi Sergey,

clearCache(index) is called from 2 places one from setGlyphPositions() 
which I fixed and other one from setGlyphTransform() and 
setGlyphTransform is called from public setGlyphTransform() which 
already have a check for IOB
if (ix < 0 || ix >= glyphs.length) {
             throw new IndexOutOfBoundsException("ix = " + ix);
         }
so this (setGlyphPositions) is the only place where it was called wrongly.

Regards
Prasanta
On 12/7/2015 9:01 PM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> Can you please confirm that we properly use clearCaches() in other 
> places of StandardGlyphVector.java?
>
> On 27.11.15 14:48, prasanta sadhukhan wrote:
>> Hi All,
>>
>> Please review a fix for jdk9
>> Bug: https://bugs.openjdk.java.net/browse/JDK-7160052
>> webrev: http://cr.openjdk.java.net/~psadhukhan/7160052/webrev.00/
>>
>> Issue:
>> GlyphVector.setGlyphPosition(int glyphIndex, Point2D
>> <imap://Sergey%2EBylokhov%40oracle%2Ecom at stbeehive.oracle.com:993/fetch%3EUID%3E/mailing%20list/2d%3E5454?header=quotebody&part=1.2.2&filename=Point2D.html> 
>> newPos)
>> can have glyphIndex "equal" to the number of glyphs in this GlyphVector
>> so if user tries to call GlyphVector.setGlyphPosition(gv.getNumGlyphs(),
>> gv.getGlyphPosition(gv.getNumGlyphs()) it throws 
>> IndexOutOfBoundsException
>>
>> Cause:
>> StandardGlyphVector maintains a glyph cache for the glyphs stored in the
>> GlyphVector via lbcache = new Shape[glyphs.length];
>>
>> When GlyphVector.setGlyphPosition() is called, it positions the glyph at
>> the specified glyphIndex|||||||||| and tries to clear the mentioned
>> glyphIndex position of cache by calling clearCache(glyphIndex)
>> But, if we pass the glyphIndex == number of glyphs, then it tries to
>> access beyond the cache array resulting in IOB.
>>
>> Fix:
>> Checked if glyphIndex passed as argument is equal to number of glyphs
>> then do not try to clear the cache as setGlyphPosition() will anyway
>> sets the position after the last glyph.
>> Also, added this check as per spec|IndexOutOfBoundsException
>> <imap://Sergey%2EBylokhov%40oracle%2Ecom at stbeehive.oracle.com:993/fetch%3EUID%3E/mailing%20list/2d%3E5454?header=quotebody&part=1.2.3&filename=IndexOutOfBoundsException.html>| 
>>
>> - if |glyphIndex| is less than 0 or greater than the number of glyphs in
>> this |GlyphVector
>> |
>> Regards
>> Prasanta
>>
>> ||||
>
>



From Sergey.Bylokhov at oracle.com  Mon Dec  7 16:03:38 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 7 Dec 2015 19:03:38 +0300
Subject: [OpenJDK 2D-Dev] [9] RFR JDK-7160052:
 GlyphVector.setGlyphPosition can throw an exception on valid input
In-Reply-To: <5665A93F.4020406@oracle.com>
References: <56584305.70605@oracle.com> <5665A659.4030205@oracle.com>
	<5665A93F.4020406@oracle.com>
Message-ID: <5665ADDA.4050304@oracle.com>

Thanks for clarification. The fix looks fine then.

On 07.12.15 18:43, prasanta sadhukhan wrote:
> Hi Sergey,
>
> clearCache(index) is called from 2 places one from setGlyphPositions()
> which I fixed and other one from setGlyphTransform() and
> setGlyphTransform is called from public setGlyphTransform() which
> already have a check for IOB
> if (ix < 0 || ix >= glyphs.length) {
>              throw new IndexOutOfBoundsException("ix = " + ix);
>          }
> so this (setGlyphPositions) is the only place where it was called wrongly.
>
> Regards
> Prasanta
> On 12/7/2015 9:01 PM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> Can you please confirm that we properly use clearCaches() in other
>> places of StandardGlyphVector.java?
>>
>> On 27.11.15 14:48, prasanta sadhukhan wrote:
>>> Hi All,
>>>
>>> Please review a fix for jdk9
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7160052
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/7160052/webrev.00/
>>>
>>> Issue:
>>> GlyphVector.setGlyphPosition(int glyphIndex, Point2D
>>> <imap://Sergey%2EBylokhov%40oracle%2Ecom at stbeehive.oracle.com:993/fetch%3EUID%3E/mailing%20list/2d%3E5454?header=quotebody&part=1.2.2&filename=Point2D.html>
>>> newPos)
>>> can have glyphIndex "equal" to the number of glyphs in this GlyphVector
>>> so if user tries to call GlyphVector.setGlyphPosition(gv.getNumGlyphs(),
>>> gv.getGlyphPosition(gv.getNumGlyphs()) it throws
>>> IndexOutOfBoundsException
>>>
>>> Cause:
>>> StandardGlyphVector maintains a glyph cache for the glyphs stored in the
>>> GlyphVector via lbcache = new Shape[glyphs.length];
>>>
>>> When GlyphVector.setGlyphPosition() is called, it positions the glyph at
>>> the specified glyphIndex|||||||||| and tries to clear the mentioned
>>> glyphIndex position of cache by calling clearCache(glyphIndex)
>>> But, if we pass the glyphIndex == number of glyphs, then it tries to
>>> access beyond the cache array resulting in IOB.
>>>
>>> Fix:
>>> Checked if glyphIndex passed as argument is equal to number of glyphs
>>> then do not try to clear the cache as setGlyphPosition() will anyway
>>> sets the position after the last glyph.
>>> Also, added this check as per spec|IndexOutOfBoundsException
>>> <imap://Sergey%2EBylokhov%40oracle%2Ecom at stbeehive.oracle.com:993/fetch%3EUID%3E/mailing%20list/2d%3E5454?header=quotebody&part=1.2.3&filename=IndexOutOfBoundsException.html>|
>>>
>>> - if |glyphIndex| is less than 0 or greater than the number of glyphs in
>>> this |GlyphVector
>>> |
>>> Regards
>>> Prasanta
>>>
>>> ||||
>>
>>
>


-- 
Best regards, Sergey.


From prasanta.sadhukhan at oracle.com  Mon Dec  7 16:04:57 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Mon, 7 Dec 2015 21:34:57 +0530
Subject: [OpenJDK 2D-Dev] [9] RFR JDK-7160052:
 GlyphVector.setGlyphPosition can throw an exception on valid input
In-Reply-To: <5665ADDA.4050304@oracle.com>
References: <56584305.70605@oracle.com> <5665A659.4030205@oracle.com>
	<5665A93F.4020406@oracle.com> <5665ADDA.4050304@oracle.com>
Message-ID: <5665AE29.2060305@oracle.com>

Thanks Sergey.
Can I get a +1 on this? Phil, are you ok with this?

Regards
Prasanta
On 12/7/2015 9:33 PM, Sergey Bylokhov wrote:
> Thanks for clarification. The fix looks fine then.
>
> On 07.12.15 18:43, prasanta sadhukhan wrote:
>> Hi Sergey,
>>
>> clearCache(index) is called from 2 places one from setGlyphPositions()
>> which I fixed and other one from setGlyphTransform() and
>> setGlyphTransform is called from public setGlyphTransform() which
>> already have a check for IOB
>> if (ix < 0 || ix >= glyphs.length) {
>>              throw new IndexOutOfBoundsException("ix = " + ix);
>>          }
>> so this (setGlyphPositions) is the only place where it was called 
>> wrongly.
>>
>> Regards
>> Prasanta
>> On 12/7/2015 9:01 PM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>> Can you please confirm that we properly use clearCaches() in other
>>> places of StandardGlyphVector.java?
>>>
>>> On 27.11.15 14:48, prasanta sadhukhan wrote:
>>>> Hi All,
>>>>
>>>> Please review a fix for jdk9
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7160052
>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/7160052/webrev.00/
>>>>
>>>> Issue:
>>>> GlyphVector.setGlyphPosition(int glyphIndex, Point2D
>>>> <imap://Sergey%2EBylokhov%40oracle%2Ecom at stbeehive.oracle.com:993/fetch%3EUID%3E/mailing%20list/2d%3E5454?header=quotebody&part=1.2.2&filename=Point2D.html> 
>>>>
>>>> newPos)
>>>> can have glyphIndex "equal" to the number of glyphs in this 
>>>> GlyphVector
>>>> so if user tries to call 
>>>> GlyphVector.setGlyphPosition(gv.getNumGlyphs(),
>>>> gv.getGlyphPosition(gv.getNumGlyphs()) it throws
>>>> IndexOutOfBoundsException
>>>>
>>>> Cause:
>>>> StandardGlyphVector maintains a glyph cache for the glyphs stored 
>>>> in the
>>>> GlyphVector via lbcache = new Shape[glyphs.length];
>>>>
>>>> When GlyphVector.setGlyphPosition() is called, it positions the 
>>>> glyph at
>>>> the specified glyphIndex|||||||||| and tries to clear the mentioned
>>>> glyphIndex position of cache by calling clearCache(glyphIndex)
>>>> But, if we pass the glyphIndex == number of glyphs, then it tries to
>>>> access beyond the cache array resulting in IOB.
>>>>
>>>> Fix:
>>>> Checked if glyphIndex passed as argument is equal to number of glyphs
>>>> then do not try to clear the cache as setGlyphPosition() will anyway
>>>> sets the position after the last glyph.
>>>> Also, added this check as per spec|IndexOutOfBoundsException
>>>> <imap://Sergey%2EBylokhov%40oracle%2Ecom at stbeehive.oracle.com:993/fetch%3EUID%3E/mailing%20list/2d%3E5454?header=quotebody&part=1.2.3&filename=IndexOutOfBoundsException.html>| 
>>>>
>>>>
>>>> - if |glyphIndex| is less than 0 or greater than the number of 
>>>> glyphs in
>>>> this |GlyphVector
>>>> |
>>>> Regards
>>>> Prasanta
>>>>
>>>> ||||
>>>
>>>
>>
>
>



From Sergey.Bylokhov at oracle.com  Mon Dec  7 16:14:15 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 7 Dec 2015 19:14:15 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8137106: EUDC (End User Defined
 Characters) are not displayed on Windows with Java 8u60+
In-Reply-To: <56620841.1010909@oracle.com>
References: <56620841.1010909@oracle.com>
Message-ID: <5665B057.3020803@oracle.com>

Hi, Phil.
It is unclear why default implementation of TrueTypeFont.open() call 
open(usePool=false)? also useFilePool vs usePool.

On 05.12.15 0:40, Phil Race wrote:
> https://bugs.openjdk.java.net/browse/JDK-8137106
> http://cr.openjdk.java.net/~prr/8137106/index.html
>
> See the bug report for a long evaluation but here is the short version.
> In order to prevent recursive creation of the FontManager we need to
> have loading the construction of the TrueTypeFont representing the EUDC
> font avoid referencing the FontManager. This is done by locally opening
> and closing the font file in just that case.
>
> This fix is designed to be low-risk as it needs backporting.
>
> A test for this is not practical as it requires a user to install an
> EUDC font which
> requires special steps different than installing a normal font.
> Manual verification will be required.
>
> -phil.


-- 
Best regards, Sergey.


From bourges.laurent at gmail.com  Mon Dec  7 16:34:09 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Mon, 7 Dec 2015 17:34:09 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned
	write accesses
Message-ID: <CAKjRUT7Q25qjhqLMtSTYJMZrFRs9m2miegBHsfp38miqoHqpTg@mail.gmail.com>

Hi,

Please review the following (critical) bug fix that ensures (4 bytes)
aligned memory accesses (Unsafe) in MarlinCache:

bug: https://bugs.openjdk.java.net/browse/JDK-8144828
webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144828.0/

Changes:
- added MarlinConst.doCheckUnsafe (false by default) to manually check
addresses
- MarlinCache: align needed bytes in copyAARowNoRLE() as the same off-heap
block is also used by copyAARowRLE_WithBlockFlags() which store RLE entries
as integer:

+        // determine need array size:+        // for RLE encoding,
position must be aligned to 4 bytes (int):+        // align - 1 = 3 so
add +3 and round-off by mask ~3 = -4+        final long needSize = pos
+ ((px_bbox1 - px0 + 3) & -4);

I did not tested on the sparc platform as I do not have one !
But it tested the patch on my linux 64 (intel).

Best regards,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151207/b9b256c8/attachment.html>

From philip.race at oracle.com  Mon Dec  7 17:21:52 2015
From: philip.race at oracle.com (Philip Race)
Date: Mon, 07 Dec 2015 09:21:52 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8137106: EUDC (End User Defined
 Characters) are not displayed on Windows with Java 8u60+
In-Reply-To: <5665B057.3020803@oracle.com>
References: <56620841.1010909@oracle.com> <5665B057.3020803@oracle.com>
Message-ID: <5665C030.1080702@oracle.com>

Yeah .. that should have been true. I'll upload a fixed patch.

-phil.

On 12/7/15, 8:14 AM, Sergey Bylokhov wrote:
> Hi, Phil.
> It is unclear why default implementation of TrueTypeFont.open() call 
> open(usePool=false)? also useFilePool vs usePool.
>
> On 05.12.15 0:40, Phil Race wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8137106
>> http://cr.openjdk.java.net/~prr/8137106/index.html
>>
>> See the bug report for a long evaluation but here is the short version.
>> In order to prevent recursive creation of the FontManager we need to
>> have loading the construction of the TrueTypeFont representing the EUDC
>> font avoid referencing the FontManager. This is done by locally opening
>> and closing the font file in just that case.
>>
>> This fix is designed to be low-risk as it needs backporting.
>>
>> A test for this is not practical as it requires a user to install an
>> EUDC font which
>> requires special steps different than installing a normal font.
>> Manual verification will be required.
>>
>> -phil.
>
>


From philip.race at oracle.com  Mon Dec  7 18:03:00 2015
From: philip.race at oracle.com (Phil Race)
Date: Mon, 07 Dec 2015 10:03:00 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8137106: EUDC (End User Defined
 Characters) are not displayed on Windows with Java 8u60+
In-Reply-To: <5665C030.1080702@oracle.com>
References: <56620841.1010909@oracle.com> <5665B057.3020803@oracle.com>
	<5665C030.1080702@oracle.com>
Message-ID: <5665C9D4.6080906@oracle.com>

Fixed : http://cr.openjdk.java.net/~prr/8137106.1/

-phil.

On 12/07/2015 09:21 AM, Philip Race wrote:
> Yeah .. that should have been true. I'll upload a fixed patch.
>
> -phil.
>
> On 12/7/15, 8:14 AM, Sergey Bylokhov wrote:
>> Hi, Phil.
>> It is unclear why default implementation of TrueTypeFont.open() call 
>> open(usePool=false)? also useFilePool vs usePool.
>>
>> On 05.12.15 0:40, Phil Race wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8137106
>>> http://cr.openjdk.java.net/~prr/8137106/index.html
>>>
>>> See the bug report for a long evaluation but here is the short version.
>>> In order to prevent recursive creation of the FontManager we need to
>>> have loading the construction of the TrueTypeFont representing the EUDC
>>> font avoid referencing the FontManager. This is done by locally opening
>>> and closing the font file in just that case.
>>>
>>> This fix is designed to be low-risk as it needs backporting.
>>>
>>> A test for this is not practical as it requires a user to install an
>>> EUDC font which
>>> requires special steps different than installing a normal font.
>>> Manual verification will be required.
>>>
>>> -phil.
>>
>>



From philip.race at oracle.com  Mon Dec  7 19:52:57 2015
From: philip.race at oracle.com (Philip Race)
Date: Mon, 07 Dec 2015 11:52:57 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8144858: HBShaper.c does not compiler with
	VS2010
Message-ID: <5665E399.1040704@oracle.com>

Bug : https://bugs.openjdk.java.net/browse/JDK-8144858
Fix  : http://cr.openjdk.java.net/~prr/8144858/

The inline declarations do not build with VS2010.
Although VS2013 is the official compiler, I see no reason we
should not support VS2010 as long as possible.

-phil.



From Sergey.Bylokhov at oracle.com  Mon Dec  7 20:03:28 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 7 Dec 2015 23:03:28 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8137106: EUDC (End User Defined
 Characters) are not displayed on Windows with Java 8u60+
In-Reply-To: <5665C9D4.6080906@oracle.com>
References: <56620841.1010909@oracle.com> <5665B057.3020803@oracle.com>
	<5665C030.1080702@oracle.com> <5665C9D4.6080906@oracle.com>
Message-ID: <5665E610.8050604@oracle.com>

On 07.12.15 21:03, Phil Race wrote:
> Fixed : http://cr.openjdk.java.net/~prr/8137106.1/

Looks fine. Probably the same name useFilePool vs usePool;

>
> -phil.
>
> On 12/07/2015 09:21 AM, Philip Race wrote:
>> Yeah .. that should have been true. I'll upload a fixed patch.
>>
>> -phil.
>>
>> On 12/7/15, 8:14 AM, Sergey Bylokhov wrote:
>>> Hi, Phil.
>>> It is unclear why default implementation of TrueTypeFont.open() call
>>> open(usePool=false)? also useFilePool vs usePool.
>>>
>>> On 05.12.15 0:40, Phil Race wrote:
>>>> https://bugs.openjdk.java.net/browse/JDK-8137106
>>>> http://cr.openjdk.java.net/~prr/8137106/index.html
>>>>
>>>> See the bug report for a long evaluation but here is the short version.
>>>> In order to prevent recursive creation of the FontManager we need to
>>>> have loading the construction of the TrueTypeFont representing the EUDC
>>>> font avoid referencing the FontManager. This is done by locally opening
>>>> and closing the font file in just that case.
>>>>
>>>> This fix is designed to be low-risk as it needs backporting.
>>>>
>>>> A test for this is not practical as it requires a user to install an
>>>> EUDC font which
>>>> requires special steps different than installing a normal font.
>>>> Manual verification will be required.
>>>>
>>>> -phil.
>>>
>>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Dec  7 20:15:31 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 7 Dec 2015 23:15:31 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8144858: HBShaper.c does not compiler
 with VS2010
In-Reply-To: <5665E399.1040704@oracle.com>
References: <5665E399.1040704@oracle.com>
Message-ID: <5665E8E3.3050400@oracle.com>

Looks fine.
On 07.12.15 22:52, Philip Race wrote:
> Bug : https://bugs.openjdk.java.net/browse/JDK-8144858
> Fix  : http://cr.openjdk.java.net/~prr/8144858/
>
> The inline declarations do not build with VS2010.
> Although VS2013 is the official compiler, I see no reason we
> should not support VS2010 as long as possible.
>
> -phil.
>


-- 
Best regards, Sergey.


From philip.race at oracle.com  Mon Dec  7 20:29:26 2015
From: philip.race at oracle.com (Phil Race)
Date: Mon, 07 Dec 2015 12:29:26 -0800
Subject: [OpenJDK 2D-Dev] CFV: New 2D Group Member: Sergey Bylokhov
Message-ID: <5665EC26.7080300@oracle.com>

I hereby nominate Sergey Bylokhov to membership in the 2D group.

Sergey has been a de facto member of the group for a long time and
has contributed numerous substantial fixes and provided many code reviews.

Votes are due by 21st December 2015.

//Only current Members of the 2D Group [1] are eligible to vote on this 
nomination.
For Lazy Consensus voting instructions, see [2].

[1] http://openjdk.java.net/census#2d <http://openjdk.java.net/census#swing>
[2] http://openjdk.java.net/groups/#member-vote 
<http://openjdk.java.net/groups/#member-vote%7C>

-phil.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151207/f31f5628/attachment.html>

From philip.race at oracle.com  Mon Dec  7 20:46:29 2015
From: philip.race at oracle.com (Phil Race)
Date: Mon, 7 Dec 2015 12:46:29 -0800
Subject: [OpenJDK 2D-Dev] CFV: New 2D Group Member: Sergey Bylokhov
In-Reply-To: <5665EC26.7080300@oracle.com>
References: <5665EC26.7080300@oracle.com>
Message-ID: <5665F025.9050403@oracle.com>

Vote: yes.

-phil.



From james.graham at oracle.com  Mon Dec  7 21:15:04 2015
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 7 Dec 2015 13:15:04 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned
 write accesses
In-Reply-To: <CAKjRUT7Q25qjhqLMtSTYJMZrFRs9m2miegBHsfp38miqoHqpTg@mail.gmail.com>
References: <CAKjRUT7Q25qjhqLMtSTYJMZrFRs9m2miegBHsfp38miqoHqpTg@mail.gmail.com>
Message-ID: <5665F6D8.9070408@oracle.com>

pos and needSize are longs.  px_bbox1 and px0 are positive ints with 
px_bbox1 known to be greater than px0 so the subtraction should not be 
able to overflow an int.  But, now that we are adding 3, is it possible 
for that calculation to overflow?  Would it be better to protect against 
that by using 3L (and -4L) even though these are theoretical issues? 
(The result of that calculation gets cast to long before adding it to 
pos anyway.)

			...jim

On 12/7/15 8:34 AM, Laurent Bourg?s wrote:
> Hi,
>
> Please review the following (critical) bug fix that ensures (4 bytes)
> aligned memory accesses (Unsafe) in MarlinCache:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8144828
> webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144828.0/
>
> Changes:
> - added MarlinConst.doCheckUnsafe (false by default) to manually check
> addresses
> - MarlinCache: align needed bytes in copyAARowNoRLE() as the same
> off-heap block is also used by copyAARowRLE_WithBlockFlags() which store
> RLE entries as integer:
>
> + // determine need array size:
> + // for RLE encoding, position must be aligned to 4 bytes (int):
> + // align - 1 = 3 so add +3 and round-off by mask ~3 = -4
> + final long needSize = pos + ((px_bbox1 - px0 + 3) & -4);
>
> I did not tested on the sparc platform as I do not have one !
> But it tested the patch on my linux 64 (intel).
>
> Best regards,
> Laurent


From bourges.laurent at gmail.com  Mon Dec  7 21:26:30 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Mon, 7 Dec 2015 22:26:30 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned
 write accesses
In-Reply-To: <5665F6D8.9070408@oracle.com>
References: <CAKjRUT7Q25qjhqLMtSTYJMZrFRs9m2miegBHsfp38miqoHqpTg@mail.gmail.com>
	<5665F6D8.9070408@oracle.com>
Message-ID: <CAKjRUT63xnexO4ovGAA0rN_JJ7vZU9sz2Je1szJ3FgGXxe8piA@mail.gmail.com>

Jim,

You are theoretical right !
However it needs a 2Gb row = px_bbox1 - px0 ! That's only possible if you
allocate an image with a single row (MAX_INT) and the shape covers that
full range !

Do you really want me to fix that impossible case ? using 3L (and -4L).

Laurent

Le 7 d?c. 2015 22:15, "Jim Graham" <james.graham at oracle.com> a ?crit :
>
> pos and needSize are longs.  px_bbox1 and px0 are positive ints with
px_bbox1 known to be greater than px0 so the subtraction should not be able
to overflow an int.  But, now that we are adding 3, is it possible for that
calculation to overflow?  Would it be better to protect against that by
using 3L (and -4L) even though these are theoretical issues? (The result of
that calculation gets cast to long before adding it to pos anyway.)
>
>                         ...jim
>
>
> On 12/7/15 8:34 AM, Laurent Bourg?s wrote:
>>
>> Hi,
>>
>> Please review the following (critical) bug fix that ensures (4 bytes)
>> aligned memory accesses (Unsafe) in MarlinCache:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8144828
>> webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144828.0/
>>
>> Changes:
>> - added MarlinConst.doCheckUnsafe (false by default) to manually check
>> addresses
>> - MarlinCache: align needed bytes in copyAARowNoRLE() as the same
>> off-heap block is also used by copyAARowRLE_WithBlockFlags() which store
>> RLE entries as integer:
>>
>> + // determine need array size:
>> + // for RLE encoding, position must be aligned to 4 bytes (int):
>> + // align - 1 = 3 so add +3 and round-off by mask ~3 = -4
>> + final long needSize = pos + ((px_bbox1 - px0 + 3) & -4);
>>
>> I did not tested on the sparc platform as I do not have one !
>> But it tested the patch on my linux 64 (intel).
>>
>> Best regards,
>> Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151207/013e6d41/attachment.html>

From bourges.laurent at gmail.com  Mon Dec  7 21:52:31 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Mon, 7 Dec 2015 22:52:31 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned
 write accesses
In-Reply-To: <CAKjRUT63xnexO4ovGAA0rN_JJ7vZU9sz2Je1szJ3FgGXxe8piA@mail.gmail.com>
References: <CAKjRUT7Q25qjhqLMtSTYJMZrFRs9m2miegBHsfp38miqoHqpTg@mail.gmail.com>
	<5665F6D8.9070408@oracle.com>
	<CAKjRUT63xnexO4ovGAA0rN_JJ7vZU9sz2Je1szJ3FgGXxe8piA@mail.gmail.com>
Message-ID: <CAKjRUT5hth+N87UnZT7NiFPQ-axPZUWJemsqvOsUfXcFptzmyA@mail.gmail.com>

Moreover, it is concretely impossible as subpixel coords implies the
maximum largest width is MAX_INT / 8 or 16 ...

I should defintely add the same point filter as done in the
DuctusRenderingEngine to filter both NaN and huge coords !

Laurent

Le 7 d?c. 2015 22:26, "Laurent Bourg?s" <bourges.laurent at gmail.com> a
?crit :
>
> Jim,
>
> You are theoretical right !
> However it needs a 2Gb row = px_bbox1 - px0 ! That's only possible if you
allocate an image with a single row (MAX_INT) and the shape covers that
full range !
>
> Do you really want me to fix that impossible case ? using 3L (and -4L).
>
> Laurent
>
> Le 7 d?c. 2015 22:15, "Jim Graham" <james.graham at oracle.com> a ?crit :
> >
> > pos and needSize are longs.  px_bbox1 and px0 are positive ints with
px_bbox1 known to be greater than px0 so the subtraction should not be able
to overflow an int.  But, now that we are adding 3, is it possible for that
calculation to overflow?  Would it be better to protect against that by
using 3L (and -4L) even though these are theoretical issues? (The result of
that calculation gets cast to long before adding it to pos anyway.)
> >
> >                         ...jim
> >
> >
> > On 12/7/15 8:34 AM, Laurent Bourg?s wrote:
> >>
> >> Hi,
> >>
> >> Please review the following (critical) bug fix that ensures (4 bytes)
> >> aligned memory accesses (Unsafe) in MarlinCache:
> >>
> >> bug: https://bugs.openjdk.java.net/browse/JDK-8144828
> >> webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144828.0/
> >>
> >> Changes:
> >> - added MarlinConst.doCheckUnsafe (false by default) to manually check
> >> addresses
> >> - MarlinCache: align needed bytes in copyAARowNoRLE() as the same
> >> off-heap block is also used by copyAARowRLE_WithBlockFlags() which
store
> >> RLE entries as integer:
> >>
> >> + // determine need array size:
> >> + // for RLE encoding, position must be aligned to 4 bytes (int):
> >> + // align - 1 = 3 so add +3 and round-off by mask ~3 = -4
> >> + final long needSize = pos + ((px_bbox1 - px0 + 3) & -4);
> >>
> >> I did not tested on the sparc platform as I do not have one !
> >> But it tested the patch on my linux 64 (intel).
> >>
> >> Best regards,
> >> Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151207/19005582/attachment.html>

From james.graham at oracle.com  Mon Dec  7 22:49:39 2015
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 7 Dec 2015 14:49:39 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144654: Improve Marlin logging
In-Reply-To: <CAKjRUT7evVLiTUzVMDYVpJw1Mfevb+gPuBgR3bCm=fwejooZLg@mail.gmail.com>
References: <CAKjRUT51G2n6=U1uJx+_H_ZqYjkbWKp4obwktWxEzyFZOW-zwA@mail.gmail.com>
	<56621704.2010302@oracle.com> <56621C42.8050807@oracle.com>
	<CAKjRUT7evVLiTUzVMDYVpJw1Mfevb+gPuBgR3bCm=fwejooZLg@mail.gmail.com>
Message-ID: <56660D03.5000302@oracle.com>

Hi Laurent,

Looks good.

Is there some way to reduce the impact of not hard-coding doMonitors for 
future benefit?  Or is that constant only for debugging modifications?

			...jim

On 12/5/15 8:54 AM, Laurent Bourg?s wrote:
> Phil & Jim,
>
> Here is the updated webrev:
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144654.1/
>
> Changes:
> - isEnableLogs() renamed to isLoggingEnabled(); I used the convention
> "is<MemberName>" even if it is not english !
> - restored doMonitors to false (as it reduces the bytecode count for
> inlining)
>
> Comments below:
>
> 2015-12-05 0:05 GMT+01:00 Jim Graham <james.graham at oracle.com
> <mailto:james.graham at oracle.com>>:
>
>     Perhaps "isLoggingEnabled()"?
>
>
> Fixed.
>
>
>     This turns a bunch of constants from having compile-time values to
>     run-time values so the javac compiler will no longer be able to
>     compile the code out of the classfiles.  On the other hand, the
>     fields are still final so the Hotspot compiler should still be able
>     to eliminate the associated code at run-time, so hopefully this had
>     no impact on performance?
>
>
> No
>
>
>
>     On 12/4/15 2:43 PM, Phil Race wrote:
>
>         139 public static boolean isEnableLogs() {
>         140 return getBoolean("sun.java2d.renderer.log", "false");
>         141 }
>
>         All of these begin with sun.java2d.renderer but they are all marlin
>         specific.
>         I guess it is OK though if we expect that ultimately marlin is
>         the only
>         renderer.
>
>
> I can later rename all Marlin system properties at once to use the
> prefix "sun.java2d.marlin" if you prefer (already discussed?).
>
>
>         "isEnable" does not read well but I know that the same pattern
>         is used for
>         everything so I don't have a firm objection although the "is"
>         seems likeit
>         is could be removed in most cases. Some may need a "do" adding
>
>
> Fixed using Jim's proposal.
>
>
>         You have deleted getCallerInfo so probably you can close
>         https://bugs.openjdk.java.net/browse/JDK-8144530 as a dup of
>         this bug.
>
>
> Done.
>
> Cheers,
> Laurent


From james.graham at oracle.com  Tue Dec  8 01:10:41 2015
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 7 Dec 2015 17:10:41 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144445: Maximum size checking in Marlin
 ArrayCache utility methods is not optimal
In-Reply-To: <CAKjRUT4B2g+FPZKYHUfXipbBhQiAy9PFxEN2v2zvntb1LmVWGg@mail.gmail.com>
References: <CAKjRUT7=puzVxKiqEGoCae_QCcw6Nu-HBZa6LvmB=Uqcf0mcyA@mail.gmail.com>
	<56621E1A.1080602@oracle.com>
	<CAKjRUT4B2g+FPZKYHUfXipbBhQiAy9PFxEN2v2zvntb1LmVWGg@mail.gmail.com>
Message-ID: <56662E11.8080408@oracle.com>

Hi Laurent,

On 12/7/15 2:17 AM, Laurent Bourg?s wrote:
>
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144445.1/
>
> See my comments below:
>
> Le 5 d?c. 2015 00:13, "Jim Graham" <james.graham at oracle.com
> <mailto:james.graham at oracle.com>> a ?crit :
>
>     ArrayCache.java line 214 - was that supposed to be size or needSize
>     on that line?
>
> 214 if (needSize < 0L || size > Integer.MAX_VALUE) {
>
> I think it is correct:
> - check size > MAX_INT to detect integer overflow
> - check needSize is negative to detect integer overflow on the needed

My point is that needSize is checked on the following line so why is it 
also checked here?  The entanglement of the size and needSize tests on 
214 and 215 is not straightforward and worrisome.

In looking this over again I notice that really the exceptions are only 
thrown on "out of range" needSize values and they are probably always 
thrown in that case, but sometimes we only discover those range issues 
if other things fail and many of the tests that lead to getting to that 
statement may or may not operate correctly depending on whether they are 
dealing with a valid needSize (for instance testing against "< needSize" 
when needSize might be negative, etc.).  It makes verifying this code 
much more difficult due to having to deal with cases where multiple 
variables might be out of range when they are computed or compared 
against each other.  To that end, it might be more straightforward to 
simply test needSize at the top and then the rest of the function can 
know it is dealing with a proper value for needSize and only has to 
worry about returning a non-overflowing number.  Knowing that needSize 
is a valid number makes any computations with it or compares against it 
have fewer "failure conditions" to note and vet.

For example:

first function:

185-189 move to the top of the function and only test needSize and then 
later on line 177 we capture any overflow since we know that needSize 
cannot be negative as well.  180,182 are then sufficient to make sure 
that the value calculated in that case will be >= needSize.

second function:

215-220 also move to the top of that function and 214 (if it compares 
size in both cases) is sufficient to make sure we are returning a value 
 >= needSize in all cases.  As it stands 210 and 212 could be computing 
random values and the tests at 214 and later are no longer complicated 
by having to consider the case that needSize itself is wrong - they only 
have to deal with whether the returned size bumped out of range.

general note:

Also, "(longval < 0L || longval > MAX_INT)" can be calculated as 
"((longval >> 31) != 0)".

> I could also check size < 0L if you want but it is only possible if
> curSize < 0 (that should never happen) !

That may be true at line 209, but then you test it against needSize and 
do more calculations where the new value of size depends only on 
needSize and so its dependence on curSize no longer offers any 
protection.  At 214 you might not be able to assert that size>=0 any 
more as a result.

>     In the test cases that expect an exception, if no exception is
>     thrown then you pass the test.  Is that right?
>
>
> Fixed.

That works.  I was thinking more along the lines of this which is more 
straightforward:

try {
     do test;
     throw new RuntimeException("AIOBException not thrown");
} catch (AIOBException e) (
     return;
} catch (Throwable t) {
     throw new RuntimeException("Wrong exception (not AIOB) thrown", t);
}

			...jim


From james.graham at oracle.com  Tue Dec  8 01:13:27 2015
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 7 Dec 2015 17:13:27 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned
 write accesses
In-Reply-To: <CAKjRUT5hth+N87UnZT7NiFPQ-axPZUWJemsqvOsUfXcFptzmyA@mail.gmail.com>
References: <CAKjRUT7Q25qjhqLMtSTYJMZrFRs9m2miegBHsfp38miqoHqpTg@mail.gmail.com>
	<5665F6D8.9070408@oracle.com>
	<CAKjRUT63xnexO4ovGAA0rN_JJ7vZU9sz2Je1szJ3FgGXxe8piA@mail.gmail.com>
	<CAKjRUT5hth+N87UnZT7NiFPQ-axPZUWJemsqvOsUfXcFptzmyA@mail.gmail.com>
Message-ID: <56662EB7.2010307@oracle.com>

Do we make sure that the subpixel coords don't overflow an integer 
somewhere?

			...jim

On 12/7/15 1:52 PM, Laurent Bourg?s wrote:
> Moreover, it is concretely impossible as subpixel coords implies the
> maximum largest width is MAX_INT / 8 or 16 ...
>
> I should defintely add the same point filter as done in the
> DuctusRenderingEngine to filter both NaN and huge coords !
>
> Laurent
>
> Le 7 d?c. 2015 22:26, "Laurent Bourg?s" <bourges.laurent at gmail.com
> <mailto:bourges.laurent at gmail.com>> a ?crit :
>>
>> Jim,
>>
>> You are theoretical right !
>> However it needs a 2Gb row = px_bbox1 - px0 ! That's only possible if you allocate an image with a single row (MAX_INT) and the shape covers that full range !
>>
>> Do you really want me to fix that impossible case ? using 3L (and -4L).
>>
>> Laurent
>>
>> Le 7 d?c. 2015 22:15, "Jim Graham" <james.graham at oracle.com <mailto:james.graham at oracle.com>> a ?crit :
>> >
>> > pos and needSize are longs.  px_bbox1 and px0 are positive ints with px_bbox1 known to be greater than px0 so the subtraction should not be able to overflow an int.  But, now that we are adding 3, is it possible for that calculation to overflow?  Would it be better to protect against that by using 3L (and -4L) even though these are theoretical issues? (The result of that calculation gets cast to long before adding it to pos anyway.)
>> >
>> >                         ...jim
>> >
>> >
>> > On 12/7/15 8:34 AM, Laurent Bourg?s wrote:
>> >>
>> >> Hi,
>> >>
>> >> Please review the following (critical) bug fix that ensures (4 bytes)
>> >> aligned memory accesses (Unsafe) in MarlinCache:
>> >>
>> >> bug:https://bugs.openjdk.java.net/browse/JDK-8144828
>> >> webrev:http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144828.0/
>> >>
>> >> Changes:
>> >> - added MarlinConst.doCheckUnsafe (false by default) to manually check
>> >> addresses
>> >> - MarlinCache: align needed bytes in copyAARowNoRLE() as the same
>> >> off-heap block is also used by copyAARowRLE_WithBlockFlags() which store
>> >> RLE entries as integer:
>> >>
>> >> + // determine need array size:
>> >> + // for RLE encoding, position must be aligned to 4 bytes (int):
>> >> + // align - 1 = 3 so add +3 and round-off by mask ~3 = -4
>> >> + final long needSize = pos + ((px_bbox1 - px0 + 3) & -4);
>> >>
>> >> I did not tested on the sparc platform as I do not have one !
>> >> But it tested the patch on my linux 64 (intel).
>> >>
>> >> Best regards,
>> >> Laurent
>


From james.graham at oracle.com  Tue Dec  8 01:30:21 2015
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 7 Dec 2015 17:30:21 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144718: Pisces / Marlin Strokers may
 generate invalid curves with huge coordinates and round joins
In-Reply-To: <CAKjRUT7KPBQ+g7aQ1Qsco-FBuxNAT9COKHn+gMsDAyJKmFYC6g@mail.gmail.com>
References: <CAKjRUT6U8+DWi8DQuWuRwQFoKVMwR8hpHFD36isDxDcw-6F-Dw@mail.gmail.com>
	<56621B00.9090309@oracle.com>
	<CAKjRUT7KPBQ+g7aQ1Qsco-FBuxNAT9COKHn+gMsDAyJKmFYC6g@mail.gmail.com>
Message-ID: <566632AD.4000908@oracle.com>

Looks good.

		...jim

On 12/5/15 8:33 AM, Laurent Bourg?s wrote:
> Jim,
>
> here is the updated webrev:
> http://cr.openjdk.java.net/~lbourges/marlin/Stroker-8144718.1/
>
> Changes:
> - added the comment you proposed
> - Marlin: use precomputed invHalfLineWidth2Sq = 1f / (2f * lineWidth2 *
> lineWidth2) for performance
> - fix copyright date in Pisces Stroker
>
> Laurent
>
> 2015-12-05 0:00 GMT+01:00 Jim Graham <james.graham at oracle.com
> <mailto:james.graham at oracle.com>>:
>
>     I'd make the test >= 0.5 since 0.5 generates a flat curve as well.
>
>     And it couldn't hurt to mention that we are worried about round off
>     error since someone coming along might wonder why we're worried that
>     a cos() is > 1:
>
>     // check round off errors producing cos(ext) > 1 and a NaN below
>     // cos(ext) == 1 implies colinear segments and an empty join anyway
>
>                      ...jim
>
>
>     On 12/4/15 8:33 AM, Laurent Bourg?s wrote:
>
>         Hi,
>
>         Please review this webrev  fixing the Stroker bug in both Pisces &
>         Marlin (same changes):
>         bug: https://bugs.openjdk.java.net/browse/JDK-8144718
>         webrev:
>         http://cr.openjdk.java.net/~lbourges/marlin/Stroker-8144718.0/
>
>         As this bug is very difficult to reproduce (artefacts), I just
>         provide a
>         simple test class that reproduces the issue.
>
>         Regards,
>         Laurent Bourg?s
>
>
>
>
> --
> --
> Laurent Bourg?s


From brian.burkhalter at oracle.com  Tue Dec  8 02:05:01 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 7 Dec 2015 18:05:01 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8144245: [PIT]
	javax/imageio/plugins/shared/WriteAfterAbort.java
In-Reply-To: <566587A4.80708@oracle.com>
References: <60DCC72E-224E-4B81-BB2E-C1F2ED1E1338@oracle.com>
	<566219FD.203@oracle.com> <566587A4.80708@oracle.com>
Message-ID: <21119D41-525B-4D69-9478-2BBF791B8DEA@oracle.com>

This is a revision of the previous patch which had been approved:

http://cr.openjdk.java.net/~bpb/8144245/webrev.01/

I was suspicious of whether the fix for the WriteAfterAbort problem was really correct in the case of writing a sequence so I wrote another test. Indeed it discovered that the TIFFImageWriter change did not work for aborting a sequence. The updated code in this patch passes both tests.

Modifications versus previous version:

Added WriteToSequenceAfterAbort test.
Corrected TIFFImageWriter to pass both tests (needed to save and restore some extra state, mainly positions).
Removed 8144245 from @bug in WriteAfterAbort as it is now present in WriteToSequenceAfterAbort.

Thanks,

Brian

On Dec 7, 2015, at 5:20 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Looks fine.
> 
> On 05.12.15 1:55, Phil Race wrote:
>> looks good.
>> 
>> -phil.
>> 
>> On 12/04/2015 02:27 PM, Brian Burkhalter wrote:
>>> Please review at your convenience.
>>> 
>>> Issue:    https://bugs.openjdk.java.net/browse/JDK-8144245
>>> Patch:    http://cr.openjdk.java.net/~bpb/8144245/webrev.00/
>>> 
>>> For the principal issue, the stream position was not being reset when
>>> the write was aborted to either the header position or to the position
>>> of the current IFD, as appropriate. As part of the investigation, a
>>> missing check in TIFFIFD was discovered. Also, a few occurrences in
>>> TIFFImageWriter of a NullPointerException being thrown where an
>>> IllegalArgumentException was expected were corrected. Lastly, the test
>>> was slightly modified to iterate over all registered writers and fail
>>> at the end instead of bailing out on the first failure.
>>> 
>>> Thanks,
>>> 
>>> Brian
>> 
> 
> 
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151207/81637394/attachment.html>

From james.graham at oracle.com  Tue Dec  8 02:16:52 2015
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 7 Dec 2015 18:16:52 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <56621A48.7020406@oracle.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
	<566219C4.303@oracle.com> <56621A48.7020406@oracle.com>
Message-ID: <56663D94.6040304@oracle.com>

Prior to pushing it I ran the test and it takes over 30 seconds to 
complete.  Is this something we want to make a manual test?

			...jim

On 12/4/15 2:57 PM, Phil Race wrote:
> Looks good.
>
> -phil.
>
> On 12/04/2015 02:55 PM, Jim Graham wrote:
>> Looks good to me.  Are jigsaw issues good Phil?
>>
>>             ...jim
>>
>> On 12/3/15 12:58 PM, Laurent Bourg?s wrote:
>>> Phil,
>>>
>>>     If you were to run this on a jigsaw EA build it would fail due to
>>>     accessing
>>>     sun.java2d.pipe.RenderingEngine. I know this is "pre-existing" but
>>>     jigsaw is coming ...
>>>
>>>
>>> You're right, sorry !
>>>
>>> Here is a new webrev:
>>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.1/
>>>
>>> Changes:
>>> - set System property "sun.java2d.renderer.verbose" to true (to get the
>>> renderer in use)
>>> - removed any RenderingEngine usage
>>>
>>> Laurent
>


From philip.race at oracle.com  Tue Dec  8 02:29:05 2015
From: philip.race at oracle.com (Phil Race)
Date: Mon, 7 Dec 2015 18:29:05 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8144245: [PIT]
	javax/imageio/plugins/shared/WriteAfterAbort.java
In-Reply-To: <21119D41-525B-4D69-9478-2BBF791B8DEA@oracle.com>
References: <60DCC72E-224E-4B81-BB2E-C1F2ED1E1338@oracle.com>
	<566219FD.203@oracle.com> <566587A4.80708@oracle.com>
	<21119D41-525B-4D69-9478-2BBF791B8DEA@oracle.com>
Message-ID: <CD350A61-AEAC-4AA1-A80D-0FCBC5026C18@oracle.com>

I suppose this modified test must pass for all the plugins ? 

-Phil.

> On Dec 7, 2015, at 6:05 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> This is a revision of the previous patch which had been approved:
> 
> http://cr.openjdk.java.net/~bpb/8144245/webrev.01/
> 
> I was suspicious of whether the fix for the WriteAfterAbort problem was really correct in the case of writing a sequence so I wrote another test. Indeed it discovered that the TIFFImageWriter change did not work for aborting a sequence. The updated code in this patch passes both tests.
> 
> Modifications versus previous version:
> 
> Added WriteToSequenceAfterAbort test.
> Corrected TIFFImageWriter to pass both tests (needed to save and restore some extra state, mainly positions).
> Removed 8144245 from @bug in WriteAfterAbort as it is now present in WriteToSequenceAfterAbort.
> 
> Thanks,
> 
> Brian
> 
>> On Dec 7, 2015, at 5:20 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>> 
>> Looks fine.
>> 
>>> On 05.12.15 1:55, Phil Race wrote:
>>> looks good.
>>> 
>>> -phil.
>>> 
>>>> On 12/04/2015 02:27 PM, Brian Burkhalter wrote:
>>>> Please review at your convenience.
>>>> 
>>>> Issue:    https://bugs.openjdk.java.net/browse/JDK-8144245
>>>> Patch:    http://cr.openjdk.java.net/~bpb/8144245/webrev.00/
>>>> 
>>>> For the principal issue, the stream position was not being reset when
>>>> the write was aborted to either the header position or to the position
>>>> of the current IFD, as appropriate. As part of the investigation, a
>>>> missing check in TIFFIFD was discovered. Also, a few occurrences in
>>>> TIFFImageWriter of a NullPointerException being thrown where an
>>>> IllegalArgumentException was expected were corrected. Lastly, the test
>>>> was slightly modified to iterate over all registered writers and fail
>>>> at the end instead of bailing out on the first failure.
>>>> 
>>>> Thanks,
>>>> 
>>>> Brian
>> 
>> 
>> -- 
>> Best regards, Sergey.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151207/db3c6d2b/attachment.html>

From jayathirth.d.v at oracle.com  Tue Dec  8 07:31:10 2015
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Mon, 7 Dec 2015 23:31:10 -0800 (PST)
Subject: [OpenJDK 2D-Dev] [9] RFR JDK-7160052:
 GlyphVector.setGlyphPosition can throw an exception on valid input
In-Reply-To: <5665ADDA.4050304@oracle.com>
References: <56584305.70605@oracle.com> <5665A659.4030205@oracle.com>
	<5665A93F.4020406@oracle.com> <5665ADDA.4050304@oracle.com>
Message-ID: <d40e5b9d-52d8-4a5c-8b21-23cccac518a6@default>

Change looks fine to me.

-----Original Message-----
From: Sergey Bylokhov 
Sent: Monday, December 07, 2015 9:34 PM
To: prasanta sadhukhan; Phil Race; 2d-dev at openjdk.java.net; Rajeev Chamyal
Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-7160052: GlyphVector.setGlyphPosition can throw an exception on valid input

Thanks for clarification. The fix looks fine then.

On 07.12.15 18:43, prasanta sadhukhan wrote:
> Hi Sergey,
>
> clearCache(index) is called from 2 places one from setGlyphPositions() 
> which I fixed and other one from setGlyphTransform() and 
> setGlyphTransform is called from public setGlyphTransform() which 
> already have a check for IOB if (ix < 0 || ix >= glyphs.length) {
>              throw new IndexOutOfBoundsException("ix = " + ix);
>          }
> so this (setGlyphPositions) is the only place where it was called wrongly.
>
> Regards
> Prasanta
> On 12/7/2015 9:01 PM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> Can you please confirm that we properly use clearCaches() in other 
>> places of StandardGlyphVector.java?
>>
>> On 27.11.15 14:48, prasanta sadhukhan wrote:
>>> Hi All,
>>>
>>> Please review a fix for jdk9
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7160052
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/7160052/webrev.00/
>>>
>>> Issue:
>>> GlyphVector.setGlyphPosition(int glyphIndex, Point2D 
>>> <imap://Sergey%2EBylokhov%40oracle%2Ecom at stbeehive.oracle.com:993/fe
>>> tch%3EUID%3E/mailing%20list/2d%3E5454?header=quotebody&part=1.2.2&fi
>>> lename=Point2D.html>
>>> newPos)
>>> can have glyphIndex "equal" to the number of glyphs in this 
>>> GlyphVector so if user tries to call 
>>> GlyphVector.setGlyphPosition(gv.getNumGlyphs(),
>>> gv.getGlyphPosition(gv.getNumGlyphs()) it throws 
>>> IndexOutOfBoundsException
>>>
>>> Cause:
>>> StandardGlyphVector maintains a glyph cache for the glyphs stored in 
>>> the GlyphVector via lbcache = new Shape[glyphs.length];
>>>
>>> When GlyphVector.setGlyphPosition() is called, it positions the 
>>> glyph at the specified glyphIndex|||||||||| and tries to clear the 
>>> mentioned glyphIndex position of cache by calling 
>>> clearCache(glyphIndex) But, if we pass the glyphIndex == number of 
>>> glyphs, then it tries to access beyond the cache array resulting in IOB.
>>>
>>> Fix:
>>> Checked if glyphIndex passed as argument is equal to number of 
>>> glyphs then do not try to clear the cache as setGlyphPosition() will 
>>> anyway sets the position after the last glyph.
>>> Also, added this check as per spec|IndexOutOfBoundsException 
>>> <imap://Sergey%2EBylokhov%40oracle%2Ecom at stbeehive.oracle.com:993/fe
>>> tch%3EUID%3E/mailing%20list/2d%3E5454?header=quotebody&part=1.2.3&fi
>>> lename=IndexOutOfBoundsException.html>|
>>>
>>> - if |glyphIndex| is less than 0 or greater than the number of 
>>> glyphs in this |GlyphVector
>>> |
>>> Regards
>>> Prasanta
>>>
>>> ||||
>>
>>
>


--
Best regards, Sergey.


From bourges.laurent at gmail.com  Tue Dec  8 07:54:51 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 8 Dec 2015 08:54:51 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <56663D94.6040304@oracle.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
	<566219C4.303@oracle.com> <56621A48.7020406@oracle.com>
	<56663D94.6040304@oracle.com>
Message-ID: <CAKjRUT7u+wm5x5eyG5o-3krMWtNwD3f_jc40zos4Gn0-CpTz9w@mail.gmail.com>

Jim,

This test is the most important for Marlin as it checks off-heap array
overflows to detect possible SEG FAULT (critical) so I really want it to be
run automatically to detect a possible regression asap.

I could add the jtreg timeout tag if you want ~ 120s (x4 typical time).

Laurent

Le 8 d?c. 2015 03:17, "Jim Graham" <james.graham at oracle.com> a ?crit :
>
> Prior to pushing it I ran the test and it takes over 30 seconds to
complete.  Is this something we want to make a manual test?
>
>                         ...jim
>
>
> On 12/4/15 2:57 PM, Phil Race wrote:
>>
>> Looks good.
>>
>> -phil.
>>
>> On 12/04/2015 02:55 PM, Jim Graham wrote:
>>>
>>> Looks good to me.  Are jigsaw issues good Phil?
>>>
>>>             ...jim
>>>
>>> On 12/3/15 12:58 PM, Laurent Bourg?s wrote:
>>>>
>>>> Phil,
>>>>
>>>>     If you were to run this on a jigsaw EA build it would fail due to
>>>>     accessing
>>>>     sun.java2d.pipe.RenderingEngine. I know this is "pre-existing" but
>>>>     jigsaw is coming ...
>>>>
>>>>
>>>> You're right, sorry !
>>>>
>>>> Here is a new webrev:
>>>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.1/
>>>>
>>>> Changes:
>>>> - set System property "sun.java2d.renderer.verbose" to true (to get the
>>>> renderer in use)
>>>> - removed any RenderingEngine usage
>>>>
>>>> Laurent
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151208/5f190668/attachment.html>

From bourges.laurent at gmail.com  Tue Dec  8 08:03:46 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 8 Dec 2015 09:03:46 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144654: Improve Marlin logging
In-Reply-To: <56660D03.5000302@oracle.com>
References: <CAKjRUT51G2n6=U1uJx+_H_ZqYjkbWKp4obwktWxEzyFZOW-zwA@mail.gmail.com>
	<56621704.2010302@oracle.com> <56621C42.8050807@oracle.com>
	<CAKjRUT7evVLiTUzVMDYVpJw1Mfevb+gPuBgR3bCm=fwejooZLg@mail.gmail.com>
	<56660D03.5000302@oracle.com>
Message-ID: <CAKjRUT5ywmsFAZ4Cu1rsESsb-DZ174BoZMz+AmTNYHqwg-WLVQ@mail.gmail.com>

Jim,

> Looks good.
>
> Is there some way to reduce the impact of not hard-coding doMonitors for
future benefit?  Or is that constant only for debugging modifications?

Durin Marlin development, I occasionally use doMonitor to get internal
timings so it is a developper feature that should remain confidential but
interesting to keep in the code (disabled by default).

The JMH perfasm profiler is better as it provides more accurate timings and
lower overhead!

Laurent

> On 12/5/15 8:54 AM, Laurent Bourg?s wrote:
>>
>> Phil & Jim,
>>
>> Here is the updated webrev:
>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144654.1/
>>
>> Changes:
>> - isEnableLogs() renamed to isLoggingEnabled(); I used the convention
>> "is<MemberName>" even if it is not english !
>> - restored doMonitors to false (as it reduces the bytecode count for
>> inlining)
>>
>> Comments below:
>>
>> 2015-12-05 0:05 GMT+01:00 Jim Graham <james.graham at oracle.com
>> <mailto:james.graham at oracle.com>>:
>>
>>
>>     Perhaps "isLoggingEnabled()"?
>>
>>
>> Fixed.
>>
>>
>>     This turns a bunch of constants from having compile-time values to
>>     run-time values so the javac compiler will no longer be able to
>>     compile the code out of the classfiles.  On the other hand, the
>>     fields are still final so the Hotspot compiler should still be able
>>     to eliminate the associated code at run-time, so hopefully this had
>>     no impact on performance?
>>
>>
>> No
>>
>>
>>
>>     On 12/4/15 2:43 PM, Phil Race wrote:
>>
>>         139 public static boolean isEnableLogs() {
>>         140 return getBoolean("sun.java2d.renderer.log", "false");
>>         141 }
>>
>>         All of these begin with sun.java2d.renderer but they are all
marlin
>>         specific.
>>         I guess it is OK though if we expect that ultimately marlin is
>>         the only
>>         renderer.
>>
>>
>> I can later rename all Marlin system properties at once to use the
>> prefix "sun.java2d.marlin" if you prefer (already discussed?).
>>
>>
>>         "isEnable" does not read well but I know that the same pattern
>>         is used for
>>         everything so I don't have a firm objection although the "is"
>>         seems likeit
>>         is could be removed in most cases. Some may need a "do" adding
>>
>>
>> Fixed using Jim's proposal.
>>
>>
>>         You have deleted getCallerInfo so probably you can close
>>         https://bugs.openjdk.java.net/browse/JDK-8144530 as a dup of
>>         this bug.
>>
>>
>> Done.
>>
>> Cheers,
>> Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151208/38b72011/attachment.html>

From bourges.laurent at gmail.com  Tue Dec  8 08:11:50 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 8 Dec 2015 09:11:50 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned
 write accesses
In-Reply-To: <56662EB7.2010307@oracle.com>
References: <CAKjRUT7Q25qjhqLMtSTYJMZrFRs9m2miegBHsfp38miqoHqpTg@mail.gmail.com>
	<5665F6D8.9070408@oracle.com>
	<CAKjRUT63xnexO4ovGAA0rN_JJ7vZU9sz2Je1szJ3FgGXxe8piA@mail.gmail.com>
	<CAKjRUT5hth+N87UnZT7NiFPQ-axPZUWJemsqvOsUfXcFptzmyA@mail.gmail.com>
	<56662EB7.2010307@oracle.com>
Message-ID: <CAKjRUT61t0qVn+6tyH-dfx3kyse7092LNicC3u4XANA3VVu-sw@mail.gmail.com>

Jim,

I think this patch fixes properly the segfault issue on sparc as confirmed
by Tobias.

Le 8 d?c. 2015 02:13, "Jim Graham" <james.graham at oracle.com> a ?crit :
>
> Do we make sure that the subpixel coords don't overflow an integer
somewhere?

I will create a new bug related to this specific issue to handle properly
coordinate overflow: NaN, Infinity and coords > MAX_INTEGER / SUBPIXEL (8).

Moreover this other bug needs many appropriate tests...

Please push that fix FIRST as it impacts the MarlinCache class and is more
critical.

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151208/33673059/attachment.html>

From volker.simonis at gmail.com  Tue Dec  8 10:12:48 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 8 Dec 2015 11:12:48 +0100
Subject: [OpenJDK 2D-Dev] RFR: 8144858: HBShaper.c does not compiler
	with VS2010
In-Reply-To: <5665E399.1040704@oracle.com>
References: <5665E399.1040704@oracle.com>
Message-ID: <CA+3eh12BX-EKcRcQ0ZZ1+X8rw6q5ia92F_pTbyFepUweTS99Ag@mail.gmail.com>

Hi Phil,

thanks for fixing this. This hit us as well.
The change looks good, just a small comment:

'prevCluster' doesn't seems to be used anywhere, so I think you can
completely remove it.

Regards,
Volker


On Mon, Dec 7, 2015 at 8:52 PM, Philip Race <philip.race at oracle.com> wrote:
> Bug : https://bugs.openjdk.java.net/browse/JDK-8144858
> Fix  : http://cr.openjdk.java.net/~prr/8144858/
>
> The inline declarations do not build with VS2010.
> Although VS2013 is the official compiler, I see no reason we
> should not support VS2010 as long as possible.
>
> -phil.
>


From abrygin at azul.com  Tue Dec  8 13:24:28 2015
From: abrygin at azul.com (Andrew Brygin)
Date: Tue, 8 Dec 2015 13:24:28 +0000
Subject: [OpenJDK 2D-Dev] CFV: New 2D Group Member: Sergey Bylokhov
In-Reply-To: <5665EC26.7080300@oracle.com>
References: <5665EC26.7080300@oracle.com>
Message-ID: <2698A542-AF47-41D7-A821-BB42982D6807@azul.com>

Vote: yes.

Thanks,
Andrew.

On Dec 7, 2015, at 11:29 PM, Phil Race <philip.race at oracle.com<mailto:philip.race at oracle.com>> wrote:

I hereby nominate Sergey Bylokhov to membership in the 2D group.

Sergey has been a de facto member of the group for a long time and
has contributed numerous substantial fixes and provided many code reviews.

Votes are due by 21st December 2015.

Only current Members of the 2D Group [1] are eligible to vote on this nomination.
For Lazy Consensus voting instructions, see [2].

[1] http://openjdk.java.net/census#2d<http://openjdk.java.net/census#swing>
[2] http://openjdk.java.net/groups/#member-vote<http://openjdk.java.net/groups/#member-vote%7C>

-phil.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151208/1ca8e773/attachment.html>

From bourges.laurent at gmail.com  Tue Dec  8 16:27:28 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 8 Dec 2015 17:27:28 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned
 write accesses
In-Reply-To: <CAKjRUT61t0qVn+6tyH-dfx3kyse7092LNicC3u4XANA3VVu-sw@mail.gmail.com>
References: <CAKjRUT7Q25qjhqLMtSTYJMZrFRs9m2miegBHsfp38miqoHqpTg@mail.gmail.com>
	<5665F6D8.9070408@oracle.com>
	<CAKjRUT63xnexO4ovGAA0rN_JJ7vZU9sz2Je1szJ3FgGXxe8piA@mail.gmail.com>
	<CAKjRUT5hth+N87UnZT7NiFPQ-axPZUWJemsqvOsUfXcFptzmyA@mail.gmail.com>
	<56662EB7.2010307@oracle.com>
	<CAKjRUT61t0qVn+6tyH-dfx3kyse7092LNicC3u4XANA3VVu-sw@mail.gmail.com>
Message-ID: <CAKjRUT77F-+Mg0MhAddLwaH_4k1BawKCG4D5Tk+Ar902m5tG+w@mail.gmail.com>

Jim,

I created the following bug to handle properly coordinate overflow:
https://bugs.openjdk.java.net/browse/JDK-8144938

Cheers,
Laurent

2015-12-08 9:11 GMT+01:00 Laurent Bourg?s <bourges.laurent at gmail.com>:

> Jim,
>
> I think this patch fixes properly the segfault issue on sparc as confirmed
> by Tobias.
>
> Le 8 d?c. 2015 02:13, "Jim Graham" <james.graham at oracle.com> a ?crit :
> >
> > Do we make sure that the subpixel coords don't overflow an integer
> somewhere?
>
> I will create a new bug related to this specific issue to handle properly
> coordinate overflow: NaN, Infinity and coords > MAX_INTEGER / SUBPIXEL (8).
>
> Moreover this other bug needs many appropriate tests...
>
> Please push that fix FIRST as it impacts the MarlinCache class and is more
> critical.
>
> Laurent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151208/c9474119/attachment.html>

From brian.burkhalter at oracle.com  Tue Dec  8 17:13:49 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 8 Dec 2015 09:13:49 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8144245: [PIT]
	javax/imageio/plugins/shared/WriteAfterAbort.java
In-Reply-To: <CD350A61-AEAC-4AA1-A80D-0FCBC5026C18@oracle.com>
References: <60DCC72E-224E-4B81-BB2E-C1F2ED1E1338@oracle.com>
	<566219FD.203@oracle.com> <566587A4.80708@oracle.com>
	<21119D41-525B-4D69-9478-2BBF791B8DEA@oracle.com>
	<CD350A61-AEAC-4AA1-A80D-0FCBC5026C18@oracle.com>
Message-ID: <18860736-652C-448F-A3BD-6707A303AA01@oracle.com>

The pre-existing WriteAfterAbort passes for all plugins; WriteToSequenceAfterAbort passes for TIFF but fails for GIF and JPEG, which are the only other plugins which can write sequences. This could be a problem in the test itself but I did not investigate further.

I see also that I need to delete lines 204-206 of WriteToSequenceAfterAbort.java.

Brian

On Dec 7, 2015, at 6:29 PM, Phil Race <philip.race at oracle.com> wrote:

> I suppose this modified test must pass for all the plugins ? 
> 
>> http://cr.openjdk.java.net/~bpb/8144245/webrev.01/
>> 
>> Added WriteToSequenceAfterAbort test.
>> Corrected TIFFImageWriter to pass both tests (needed to save and restore some extra state, mainly positions).
>> Removed 8144245 from @bug in WriteAfterAbort as it is now present in WriteToSequenceAfterAbort.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151208/1d4680f0/attachment.html>

From volker.simonis at gmail.com  Tue Dec  8 18:50:15 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 8 Dec 2015 19:50:15 +0100
Subject: [OpenJDK 2D-Dev] Question regarding the integration of harfbuzz
	(JEP 258)
Message-ID: <CA+3eh12NQnRhV85qNrB3Jqeu8Oq9-4utb0f+zXKsYgTNG1Qmcg@mail.gmail.com>

Hi,

the integration of harfbuzz broke our AIX build because there's no
implementation available for the hb_atomic macros in
hb-atomic-private.hh. I've fixed that locally but still get a crash
when running a simple AWT program (even with
-Dsun.font.layoutengine=icu).

I'm curretnly debugging the problem, but I have some general questions:

1. Do we really need the multi-threaded features of harfbuzz in OpenJDK?

2. Why does hurbuzz require these synchronization macros? From a first
glance it doesn't seem to use multiple threads by itself. Does it have
some global data structures which it needs to protect if harfbuzz is
called from various threads?

3. Is there a way to test the hurfbuzz engine on a new platform? I saw
the new test TestLayoutVsICU.java but it is marked as "manual" and it
seems to require external fonts (at least some of which seem to be
freely available). Could you please provide at least a minimal
description on how this test can be run?

4. Is there a way to test that the implementation of the hb_atomic
macros in hb-atomic-private.hh is correct (i.e. a way to stress
harfbuzz from multiple threads)? I think this is important as I
couldn't find a good description of the requirements for the atomic
macros and on weak memory model architectures we should really get
this right. For example there's no description of which fences are
required around the various atomic operations. Getting this right
across all platforms in the HotSpot (see
hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp) is already hard
enough so I'm a little concerned that we are now introducing similar
primitives in the class library.

Thank you and best regards,
Volker


From jennifer.godinez at oracle.com  Tue Dec  8 20:33:26 2015
From: jennifer.godinez at oracle.com (Jennifer Godinez)
Date: Tue, 08 Dec 2015 12:33:26 -0800
Subject: [OpenJDK 2D-Dev] CFV: New 2D Group Member: Sergey Bylokhov
In-Reply-To: <5665EC26.7080300@oracle.com>
References: <5665EC26.7080300@oracle.com>
Message-ID: <56673E96.3050201@oracle.com>

Vote: Yes

-  Jennifer
On 12/07/2015 12:29 PM, Phil Race wrote:
> I hereby nominate Sergey Bylokhov to membership in the 2D group.
>
> Sergey has been a de facto member of the group for a long time and
> has contributed numerous substantial fixes and provided many code reviews.
>
> Votes are due by 21st December 2015.
>
> //Only current Members of the 2D Group [1] are eligible to vote on 
> this nomination.
> For Lazy Consensus voting instructions, see [2].
>
> [1] http://openjdk.java.net/census#2d 
> <http://openjdk.java.net/census#swing>
> [2] http://openjdk.java.net/groups/#member-vote 
> <http://openjdk.java.net/groups/#member-vote%7C>
>
> -phil.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151208/2ef87623/attachment.html>

From abrygin at azul.com  Tue Dec  8 13:17:10 2015
From: abrygin at azul.com (Andrew Brygin)
Date: Tue, 8 Dec 2015 13:17:10 +0000
Subject: [OpenJDK 2D-Dev] CFV: New 2D Group Member: Sergey Bylokhov
In-Reply-To: <5665EC26.7080300@oracle.com>
References: <5665EC26.7080300@oracle.com>
Message-ID: <C113D4F4-0B46-4F86-A702-A7742AEC22F3@azul.com>

Vote: yes.

Thanks,
Andrew.

On Dec 7, 2015, at 11:29 PM, Phil Race <philip.race at oracle.com<mailto:philip.race at oracle.com>> wrote:

I hereby nominate Sergey Bylokhov to membership in the 2D group.

Sergey has been a de facto member of the group for a long time and
has contributed numerous substantial fixes and provided many code reviews.

Votes are due by 21st December 2015.

Only current Members of the 2D Group [1] are eligible to vote on this nomination.
For Lazy Consensus voting instructions, see [2].

[1] http://openjdk.java.net/census#2d<http://openjdk.java.net/census#swing>
[2] http://openjdk.java.net/groups/#member-vote<http://openjdk.java.net/groups/#member-vote%7C>

-phil.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151208/32e6ef89/attachment.html>

From james.graham at oracle.com  Tue Dec  8 23:12:02 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 8 Dec 2015 15:12:02 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <CAKjRUT7u+wm5x5eyG5o-3krMWtNwD3f_jc40zos4Gn0-CpTz9w@mail.gmail.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
	<566219C4.303@oracle.com> <56621A48.7020406@oracle.com>
	<56663D94.6040304@oracle.com>
	<CAKjRUT7u+wm5x5eyG5o-3krMWtNwD3f_jc40zos4Gn0-CpTz9w@mail.gmail.com>
Message-ID: <566763C2.7070800@oracle.com>

Hi Laurent,

If this were testing a bug that crossed a number of implementation 
boundaries such that any number of engineers might make a change that 
could cause it to fail, then I might agree with the need to run it 
whenever any automated run of tests occurs.

But, the only thing that will cause this to fail would be if someone 
modified Marlin - which is basically you, and maybe 1 or 2 other 
engineers who would only go in for mostly logistical coding reasons, not 
for any changes that might affect the algorithm.  Those engineers should 
be running the tests with the -manual option specified for testing their 
changes.

But, if someone changes some code in core libs, or Swing, or somewhere 
else not related to Marlin - you've just added 30 seconds to the amount 
of time that it takes them to test for any regressions.  Is that 
appropriate?

			...jim

On 12/7/15 11:54 PM, Laurent Bourg?s wrote:
> Jim,
>
> This test is the most important for Marlin as it checks off-heap array
> overflows to detect possible SEG FAULT (critical) so I really want it to
> be run automatically to detect a possible regression asap.
>
> I could add the jtreg timeout tag if you want ~ 120s (x4 typical time).
>
> Laurent
>
> Le 8 d?c. 2015 03:17, "Jim Graham" <james.graham at oracle.com
> <mailto:james.graham at oracle.com>> a ?crit :
>>
>> Prior to pushing it I ran the test and it takes over 30 seconds to complete.  Is this something we want to make a manual test?
>>
>>                         ...jim
>>
>>
>> On 12/4/15 2:57 PM, Phil Race wrote:
>>>
>>> Looks good.
>>>
>>> -phil.
>>>
>>> On 12/04/2015 02:55 PM, Jim Graham wrote:
>>>>
>>>> Looks good to me.  Are jigsaw issues good Phil?
>>>>
>>>>             ...jim
>>>>
>>>> On 12/3/15 12:58 PM, Laurent Bourg?s wrote:
>>>>>
>>>>> Phil,
>>>>>
>>>>>     If you were to run this on a jigsaw EA build it would fail due to
>>>>>     accessing
>>>>>     sun.java2d.pipe.RenderingEngine. I know this is "pre-existing" but
>>>>>     jigsaw is coming ...
>>>>>
>>>>>
>>>>> You're right, sorry !
>>>>>
>>>>> Here is a new webrev:
>>>>>http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.1/
>>>>>
>>>>> Changes:
>>>>> - set System property "sun.java2d.renderer.verbose" to true (to get the
>>>>> renderer in use)
>>>>> - removed any RenderingEngine usage
>>>>>
>>>>> Laurent
>>>
>>>
>


From james.graham at oracle.com  Tue Dec  8 23:17:21 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 8 Dec 2015 15:17:21 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned
 write accesses
In-Reply-To: <56662EB7.2010307@oracle.com>
References: <CAKjRUT7Q25qjhqLMtSTYJMZrFRs9m2miegBHsfp38miqoHqpTg@mail.gmail.com>
	<5665F6D8.9070408@oracle.com>
	<CAKjRUT63xnexO4ovGAA0rN_JJ7vZU9sz2Je1szJ3FgGXxe8piA@mail.gmail.com>
	<CAKjRUT5hth+N87UnZT7NiFPQ-axPZUWJemsqvOsUfXcFptzmyA@mail.gmail.com>
	<56662EB7.2010307@oracle.com>
Message-ID: <56676501.9040104@oracle.com>

With the submission of JDK-8144938 as a follow-on bug, this fix looks 
fine now...

			...jim

On 12/7/15 5:13 PM, Jim Graham wrote:
> Do we make sure that the subpixel coords don't overflow an integer
> somewhere?
>
>              ...jim
>
> On 12/7/15 1:52 PM, Laurent Bourg?s wrote:
>> Moreover, it is concretely impossible as subpixel coords implies the
>> maximum largest width is MAX_INT / 8 or 16 ...
>>
>> I should defintely add the same point filter as done in the
>> DuctusRenderingEngine to filter both NaN and huge coords !
>>
>> Laurent
>>
>> Le 7 d?c. 2015 22:26, "Laurent Bourg?s" <bourges.laurent at gmail.com
>> <mailto:bourges.laurent at gmail.com>> a ?crit :
>>>
>>> Jim,
>>>
>>> You are theoretical right !
>>> However it needs a 2Gb row = px_bbox1 - px0 ! That's only possible if
>>> you allocate an image with a single row (MAX_INT) and the shape
>>> covers that full range !
>>>
>>> Do you really want me to fix that impossible case ? using 3L (and -4L).
>>>
>>> Laurent
>>>
>>> Le 7 d?c. 2015 22:15, "Jim Graham" <james.graham at oracle.com
>>> <mailto:james.graham at oracle.com>> a ?crit :
>>> >
>>> > pos and needSize are longs.  px_bbox1 and px0 are positive ints with px_bbox1 known to be greater than px0 so the subtraction should not be able to overflow an int.  But, now that we are adding 3, is it possible for that calculation to overflow?  Would it be better to protect against that by using 3L (and -4L) even though these are theoretical issues? (The result of that calculation gets cast to long before adding it to pos anyway.)
>>> >
>>> >                         ...jim
>>> >
>>> >
>>> > On 12/7/15 8:34 AM, Laurent Bourg?s wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> Please review the following (critical) bug fix that ensures (4 bytes)
>>> >> aligned memory accesses (Unsafe) in MarlinCache:
>>> >>
>>> >> bug:https://bugs.openjdk.java.net/browse/JDK-8144828
>>> >> webrev:http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144828.0/
>>> >>
>>> >> Changes:
>>> >> - added MarlinConst.doCheckUnsafe (false by default) to manually check
>>> >> addresses
>>> >> - MarlinCache: align needed bytes in copyAARowNoRLE() as the same
>>> >> off-heap block is also used by copyAARowRLE_WithBlockFlags() which store
>>> >> RLE entries as integer:
>>> >>
>>> >> + // determine need array size:
>>> >> + // for RLE encoding, position must be aligned to 4 bytes (int):
>>> >> + // align - 1 = 3 so add +3 and round-off by mask ~3 = -4
>>> >> + final long needSize = pos + ((px_bbox1 - px0 + 3) & -4);
>>> >>
>>> >> I did not tested on the sparc platform as I do not have one !
>>> >> But it tested the patch on my linux 64 (intel).
>>> >>
>>> >> Best regards,
>>> >> Laurent
>>


From james.graham at oracle.com  Tue Dec  8 23:27:59 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 8 Dec 2015 15:27:59 -0800
Subject: [OpenJDK 2D-Dev] CFV: New 2D Group Member: Sergey Bylokhov
In-Reply-To: <5665EC26.7080300@oracle.com>
References: <5665EC26.7080300@oracle.com>
Message-ID: <5667677F.1090408@oracle.com>

Vote: yes

	...jim


From prasanta.sadhukhan at oracle.com  Wed Dec  9 07:31:34 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Wed, 9 Dec 2015 13:01:34 +0530
Subject: [OpenJDK 2D-Dev] <OpenJDK 2D-Dev> Review request for
 JDK-8143562: JPEG reader returns null for getRawImageType()
In-Reply-To: <45125a5d-a274-4321-9510-dc0e8774d505@default>
References: <45125a5d-a274-4321-9510-dc0e8774d505@default>
Message-ID: <5667D8D6.3030803@oracle.com>

The fix looks good to me.
The spec says "Returns an |ImageTypeSpecifier| indicating the 
|SampleModel| and |ColorModel| which most closely represents the "raw" 
internal format of the image. For example, for a JPEG image the raw type 
might have a YCbCr color space even though the image would 
conventionally be transformed into an RGB color space prior to display."
Also,

private Iterator<ImageTypeSpecifier> getImageTypesOnThread(int imageIndex)adds RGB for YcbCr raw type

case JPEG.JCS_YCbCr:
  832             // As there is no YCbCr ColorSpace, we can't support
  833             // the raw type.
  834
  835             // due to 4705399, use RGB as default in order to avoid
  836             // slowing down of drawing operations with result image.
  837             list.add(getImageType(JPEG.JCS_RGB));



Regards
Prasanta
On 12/1/2015 3:42 PM, Jayathirth D V wrote:
>
> Hi,
>
> _Please review following fix in JDK9:_
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8143562
>
> Webrev : http://cr.openjdk.java.net/~jdv/8143562/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ejdv/8143562/webrev.00/>
>
> Issue : We are getting null for ImageTypeSpecifier when we use 
> getRawImageType() API for YCbCr Image.
>
> Root cause : When colorspace is YCbCr, there is no condition to create 
> ImageTypeSpecifier in produce() function
>
> Solution : Since we add RGB as default ImageType for YCbCr colorspace 
> in getImageTypes() API. Followed same approach
>
>                     and considering it as RGB in getRawImageType().
>
> Thanks,
>
> Jay
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151209/d87bf9ac/attachment.html>

From bourges.laurent at gmail.com  Wed Dec  9 12:35:37 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 9 Dec 2015 13:35:37 +0100
Subject: [OpenJDK 2D-Dev] RFR :
Message-ID: <CAKjRUT4RdOfjSOvB5z2s-txbA2w-mHRUg=CYz3m81MdioE-sDw@mail.gmail.com>

Hi,

Please review this webrev fixing the long-standing bug in imageio
PNGImageWriter to support compression levels:
bug: https://bugs.openjdk.java.net/browse/JDK-6488522
webrev: http://cr.openjdk.java.net/~lbourges/png/PNGWriter-6488522.0/

Changes:
- default Deflater level changed from 9 (best) to 4 (medium)
- added compression parameter support (mode, quality)
- added missing @Override and fixed several warnings (public modifiers)

Best regards,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151209/7671f112/attachment.html>

From bourges.laurent at gmail.com  Wed Dec  9 12:36:24 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 9 Dec 2015 13:36:24 +0100
Subject: [OpenJDK 2D-Dev] RFR 6488522: PNG writer should permit setting
 compression level and iDAT chunk maximum size
Message-ID: <CAKjRUT4T7L8cK=SP0QM1LK-azLNexA0RNoq2FEFSdbSFetYr6g@mail.gmail.com>

Hi,

Please review this webrev fixing the long-standing bug in imageio
PNGImageWriter to support compression levels:
bug: https://bugs.openjdk.java.net/browse/JDK-6488522
webrev: http://cr.openjdk.java.net/~lbourges/png/PNGWriter-6488522.0/

Changes:
- default Deflater level changed from 9 (best) to 4 (medium)
- added compression parameter support (mode, quality)
- added missing @Override and fixed several warnings (public modifiers)

Best regards,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151209/85ddb35d/attachment.html>

From bourges.laurent at gmail.com  Wed Dec  9 12:37:14 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 9 Dec 2015 13:37:14 +0100
Subject: [OpenJDK 2D-Dev] RFR :
In-Reply-To: <CAKjRUT4RdOfjSOvB5z2s-txbA2w-mHRUg=CYz3m81MdioE-sDw@mail.gmail.com>
References: <CAKjRUT4RdOfjSOvB5z2s-txbA2w-mHRUg=CYz3m81MdioE-sDw@mail.gmail.com>
Message-ID: <CAKjRUT7dPHyhKS3GfDXWdo2saUJL_t4guUG3ruwUBfPUiuE04g@mail.gmail.com>

Sorry I forgot to fill the mail subject !

I have sent another email.

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151209/f35d50b0/attachment.html>

From Sergey.Bylokhov at oracle.com  Wed Dec  9 12:57:57 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 9 Dec 2015 15:57:57 +0300
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <566763C2.7070800@oracle.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
	<566219C4.303@oracle.com> <56621A48.7020406@oracle.com>
	<56663D94.6040304@oracle.com>
	<CAKjRUT7u+wm5x5eyG5o-3krMWtNwD3f_jc40zos4Gn0-CpTz9w@mail.gmail.com>
	<566763C2.7070800@oracle.com>
Message-ID: <56682555.9020809@oracle.com>

On 09/12/15 02:12, Jim Graham wrote:
> Hi Laurent,
>
> If this were testing a bug that crossed a number of implementation
> boundaries such that any number of engineers might make a change that
> could cause it to fail, then I might agree with the need to run it
> whenever any automated run of tests occurs.
>
> But, the only thing that will cause this to fail would be if someone
> modified Marlin - which is basically you, and maybe 1 or 2 other
> engineers who would only go in for mostly logistical coding reasons, not
> for any changes that might affect the algorithm.  Those engineers should
> be running the tests with the -manual option specified for testing their
> changes.
>
> But, if someone changes some code in core libs, or Swing, or somewhere
> else not related to Marlin - you've just added 30 seconds to the amount
> of time that it takes them to test for any regressions.  Is that
> appropriate?

My opinion yes. I doubt that someone will try to run manual 
tests(especially in case of future backports). The things which can be 
done automatically should be done in this way. Note that core libs team 
will not be affected because the jtreg now have a TEST.groups which 
allow run the test for one specific area like jdk_math, jdk_nio, 
jdk_lang, jdk_desktop etc.(the full list is in the jdk/test/TEST.groups)

I am not sure, but should these tests be marlin specific? I do not see 
that they have some marlin specific options and they can cover 
other(old/future) renders as well.

>
>              ...jim
>
> On 12/7/15 11:54 PM, Laurent Bourg?s wrote:
>> Jim,
>>
>> This test is the most important for Marlin as it checks off-heap array
>> overflows to detect possible SEG FAULT (critical) so I really want it to
>> be run automatically to detect a possible regression asap.
>>
>> I could add the jtreg timeout tag if you want ~ 120s (x4 typical time).
>>
>> Laurent
>>
>> Le 8 d?c. 2015 03:17, "Jim Graham" <james.graham at oracle.com
>> <mailto:james.graham at oracle.com>> a ?crit :
>>>
>>> Prior to pushing it I ran the test and it takes over 30 seconds to
>>> complete.  Is this something we want to make a manual test?
>>>
>>>                         ...jim
>>>
>>>
>>> On 12/4/15 2:57 PM, Phil Race wrote:
>>>>
>>>> Looks good.
>>>>
>>>> -phil.
>>>>
>>>> On 12/04/2015 02:55 PM, Jim Graham wrote:
>>>>>
>>>>> Looks good to me.  Are jigsaw issues good Phil?
>>>>>
>>>>>             ...jim
>>>>>
>>>>> On 12/3/15 12:58 PM, Laurent Bourg?s wrote:
>>>>>>
>>>>>> Phil,
>>>>>>
>>>>>>     If you were to run this on a jigsaw EA build it would fail due to
>>>>>>     accessing
>>>>>>     sun.java2d.pipe.RenderingEngine. I know this is "pre-existing"
>>>>>> but
>>>>>>     jigsaw is coming ...
>>>>>>
>>>>>>
>>>>>> You're right, sorry !
>>>>>>
>>>>>> Here is a new webrev:
>>>>>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.1/
>>>>>>
>>>>>> Changes:
>>>>>> - set System property "sun.java2d.renderer.verbose" to true (to
>>>>>> get the
>>>>>> renderer in use)
>>>>>> - removed any RenderingEngine usage
>>>>>>
>>>>>> Laurent
>>>>
>>>>
>>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Dec  9 13:19:26 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 9 Dec 2015 16:19:26 +0300
Subject: [OpenJDK 2D-Dev] RFR 6488522: PNG writer should permit setting
 compression level and iDAT chunk maximum size
In-Reply-To: <CAKjRUT4T7L8cK=SP0QM1LK-azLNexA0RNoq2FEFSdbSFetYr6g@mail.gmail.com>
References: <CAKjRUT4T7L8cK=SP0QM1LK-azLNexA0RNoq2FEFSdbSFetYr6g@mail.gmail.com>
Message-ID: <56682A5E.6080904@oracle.com>

Hi, Laurent.
Should the test check the resulted image in the file? At least it can 
check that the CompressionMode is not ignored and the saved files have 
different size/content for different modes? Also I think in the test we 
can cover all plugins which canWriteCompressed=true?

On 09/12/15 15:36, Laurent Bourg?s wrote:
> Hi,
>
> Please review this webrev fixing the long-standing bug in imageio
> PNGImageWriter to support compression levels:
> bug: https://bugs.openjdk.java.net/browse/JDK-6488522
> webrev: http://cr.openjdk.java.net/~lbourges/png/PNGWriter-6488522.0/
> <http://cr.openjdk.java.net/%7Elbourges/png/PNGWriter-6488522.0/>
>
> Changes:
> - default Deflater level changed from 9 (best) to 4 (medium)
> - added compression parameter support (mode, quality)
> - added missing @Override and fixed several warnings (public modifiers)
>
> Best regards,
> Laurent


-- 
Best regards, Sergey.


From bourges.laurent at gmail.com  Wed Dec  9 14:17:13 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 9 Dec 2015 15:17:13 +0100
Subject: [OpenJDK 2D-Dev] RFR 6488522: PNG writer should permit setting
 compression level and iDAT chunk maximum size
In-Reply-To: <56682A5E.6080904@oracle.com>
References: <CAKjRUT4T7L8cK=SP0QM1LK-azLNexA0RNoq2FEFSdbSFetYr6g@mail.gmail.com>
	<56682A5E.6080904@oracle.com>
Message-ID: <CAKjRUT5fu6fj1ugZ3Yf+C_RzNxRxqVyTb5my2GW5v=jr+n1+dA@mail.gmail.com>

Hi Sergey,

Thanks for your comments, did you review the PNGImageWriter changes too ?

2015-12-09 14:19 GMT+01:00 Sergey Bylokhov <Sergey.Bylokhov at oracle.com>:

> Hi, Laurent.
> Should the test check the resulted image in the file? At least it can
> check that the CompressionMode is not ignored and the saved files have
> different size/content for different modes?
>

Yes, I could check that every png file is not zero-length or that better
compression gives smaller file size !

FYI I manually checked generated files: images are OK (readable by firefox)
and file sizes are correct:

-rw-rw-r-- 1 bourgesl bourgesl   4014 d?c.   9 13:19
PNGWriterCompressionTest-explicit-0.0.png
-rw-rw-r-- 1 bourgesl bourgesl   4137 d?c.   9 13:19
PNGWriterCompressionTest-explicit-0.1.png
-rw-rw-r-- 1 bourgesl bourgesl   5046 d?c.   9 13:19
PNGWriterCompressionTest-explicit-0.2.png
-rw-rw-r-- 1 bourgesl bourgesl   5051 d?c.   9 13:19
PNGWriterCompressionTest-explicit-0.3.png
-rw-rw-r-- 1 bourgesl bourgesl   6322 d?c.   9 13:19
PNGWriterCompressionTest-explicit-0.4.png
-rw-rw-r-- 1 bourgesl bourgesl   7431 d?c.   9 13:19
PNGWriterCompressionTest-explicit-0.5.png

*-rw-rw-r-- 1 bourgesl bourgesl   7431 d?c.   9 13:19
PNGWriterCompressionTest-default.png*-rw-rw-r-- 1 bourgesl bourgesl   7431
d?c.   9 13:19 PNGWriterCompressionTest-explicit-0.6.png
-rw-rw-r-- 1 bourgesl bourgesl   8292 d?c.   9 13:19
PNGWriterCompressionTest-explicit-0.7.png
-rw-rw-r-- 1 bourgesl bourgesl   8890 d?c.   9 13:19
PNGWriterCompressionTest-explicit-0.8.png
-rw-rw-r-- 1 bourgesl bourgesl  10563 d?c.   9 13:19
PNGWriterCompressionTest-explicit-0.9.png
-rw-rw-r-- 1 bourgesl bourgesl 250437 d?c.   9 13:19
PNGWriterCompressionTest-explicit-1.0.png

*-rw-rw-r-- 1 bourgesl bourgesl 250437 d?c.   9 13:19
PNGWriterCompressionTest-disabled.png*
However, my changes rely on the public Deflater API that supports
compression levels between 0 to 9.

I suppose that this Deflater class is already covered by its own tests so I
would prefer leaving the test as it is (no verification):  if the Deflater
raises any RuntimeException, then the PNGWriterCompressionTest will fail.

Also I think in the test we can cover all plugins which
> canWriteCompressed=true?
>

Why not but it is a different scope ?

I wrote the test focused on testing my patch to validate all my changes and
fix ASAP that very old bug (created in 2006) !

Moreover, I do not really know other imageio writers (jpg, bmp, tiff ...) !
Maybe other compression tests could be derived from the
PNGWriterCompressionTest class and I think it should be part of other bugs.

Regards,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151209/accfa48e/attachment.html>

From bourges.laurent at gmail.com  Wed Dec  9 14:35:33 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 9 Dec 2015 15:35:33 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <56682555.9020809@oracle.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
	<566219C4.303@oracle.com> <56621A48.7020406@oracle.com>
	<56663D94.6040304@oracle.com>
	<CAKjRUT7u+wm5x5eyG5o-3krMWtNwD3f_jc40zos4Gn0-CpTz9w@mail.gmail.com>
	<566763C2.7070800@oracle.com> <56682555.9020809@oracle.com>
Message-ID: <CAKjRUT7qLSdYaBvN5Ci6HouP06iUJvefbGAYGikJF_Z4s4kNrg@mail.gmail.com>

Jim & Sergey,

Here are my comments:

2015-12-09 13:57 GMT+01:00 Sergey Bylokhov <Sergey.Bylokhov at oracle.com>:

> On 09/12/15 02:12, Jim Graham wrote:
>
>> Hi Laurent,
>>
>> If this were testing a bug that crossed a number of implementation
>> boundaries such that any number of engineers might make a change that
>> could cause it to fail, then I might agree with the need to run it
>> whenever any automated run of tests occurs.
>>
>
Marlin relies on the jdk.internal.Unsafe implementation depending on the
low-level JVM which is different among supported platforms (Windows, MacOS,
linux, sparc, AIX, aarch) 32/64 bits !

So I am really interested by having such cross-platform test reports.
Would have the CrashTest detected the Marlin issue on sparc ?


> But, the only thing that will cause this to fail would be if someone
>> modified Marlin - which is basically you, and maybe 1 or 2 other
>> engineers who would only go in for mostly logistical coding reasons, not
>> for any changes that might affect the algorithm.  Those engineers should
>> be running the tests with the -manual option specified for testing their
>> changes.
>>
>
Agreed it is possible but then the bug JDK-8144446
<https://bugs.openjdk.java.net/browse/JDK-8144446> becomes invalid.


> But, if someone changes some code in core libs, or Swing, or somewhere
>> else not related to Marlin - you've just added 30 seconds to the amount
>> of time that it takes them to test for any regressions.  Is that
>> appropriate?
>>
>
> My opinion yes. I doubt that someone will try to run manual
> tests(especially in case of future backports). The things which can be done
> automatically should be done in this way. Note that core libs team will not
> be affected because the jtreg now have a TEST.groups which allow run the
> test for one specific area like jdk_math, jdk_nio, jdk_lang, jdk_desktop
> etc.(the full list is in the jdk/test/TEST.groups)
>

I agree that's why I like automated regression tests.

I am not sure, but should these tests be marlin specific? I do not see that
> they have some marlin specific options and they can cover other(old/future)
> renders as well.


The test is not really specific to the Marlin renderer except it uses some
particular threshold values to exceed 2Gb limits or internal buffers.

Unfortunately only Marlin passes the CrashTest !

Here are the Pisces / Ductus failures I got:

- Pisces FAIL:
---
testHugeImage: width=8388609, height=10
image size = 8388609 x 10
paint: duration= 601.486811 ms.
---
test: lineStroke=0.1, useDashes=false, dashMinLen=0.0
image size = 9000
draw : 20200 lines.
paint: duration= 22441.869121 ms.
---
test: lineStroke=0.1, useDashes=true, dashMinLen=7.0
image size = 9000
draw : 20200 lines.
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -1
    at sun.java2d.pisces.Renderer$ScanlineIterator.next(Renderer.java:73)
    at
sun.java2d.pisces.Renderer$ScanlineIterator.access$600(Renderer.java:32)
    at sun.java2d.pisces.Renderer._endRendering(Renderer.java:450)
    at sun.java2d.pisces.Renderer.endRendering(Renderer.java:534)
    at
sun.java2d.pisces.PiscesRenderingEngine.getAATileGenerator(PiscesRenderingEngine.java:564)
    at sun.java2d.pipe.AAShapePipe.renderPath(AAShapePipe.java:152)
    at sun.java2d.pipe.AAShapePipe.draw(AAShapePipe.java:64)
    at
sun.java2d.pipe.PixelToParallelogramConverter.draw(PixelToParallelogramConverter.java:148)
    at sun.java2d.pipe.ValidatePipe.draw(ValidatePipe.java:154)
    at sun.java2d.SunGraphics2D.draw(SunGraphics2D.java:2461)
    at CrashTest.paint(CrashTest.java:254)
    at CrashTest.test(CrashTest.java:130)
    at CrashTest.main(CrashTest.java:63)

- Ductus FAIL:

testHugeImage: width=8388609, height=10
image size = 8388609 x 10
DuctusRenderingEngine.getAATileGenerator: sun.dc.pr.PRException:
setOutputArea: alpha coordinate out of bounds
Exception in thread "main" sun.dc.pr.PRError: getTileState: unexpected
    at sun.dc.pr.PathFiller.getTileState(Native Method)
    at sun.dc.pr.Rasterizer.getTypicalAlpha(Rasterizer.java:751)
    at sun.java2d.pipe.AAShapePipe.renderTiles(AAShapePipe.java:185)
    at sun.java2d.pipe.AAShapePipe.renderPath(AAShapePipe.java:159)
    at sun.java2d.pipe.AAShapePipe.draw(AAShapePipe.java:64)
    at
sun.java2d.pipe.PixelToParallelogramConverter.draw(PixelToParallelogramConverter.java:148)
    at sun.java2d.pipe.ValidatePipe.draw(ValidatePipe.java:154)
    at sun.java2d.SunGraphics2D.draw(SunGraphics2D.java:2497)
    at CrashTest.testHugeImage(CrashTest.java:185)
    at CrashTest.main(CrashTest.java:60)

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151209/064452cf/attachment.html>

From philip.race at oracle.com  Wed Dec  9 17:02:33 2015
From: philip.race at oracle.com (Philip Race)
Date: Wed, 09 Dec 2015 09:02:33 -0800
Subject: [OpenJDK 2D-Dev] Question regarding the integration of harfbuzz
 (JEP 258)
In-Reply-To: <CA+3eh12NQnRhV85qNrB3Jqeu8Oq9-4utb0f+zXKsYgTNG1Qmcg@mail.gmail.com>
References: <CA+3eh12NQnRhV85qNrB3Jqeu8Oq9-4utb0f+zXKsYgTNG1Qmcg@mail.gmail.com>
Message-ID: <56685EA9.8020704@oracle.com>

Hi Volker,

Running with ICU should stop harfbuzz use completely so if
you are still seeing a crash, perhaps it is due to something else entirely.
Especially since a "simple AWT program" should not load layout anyway.
There was a fair amount of new and changed code pushed recently ...

Yes, we need to run harfbuzz in multiple concurrent threads in the JDK.
A single threaded lock on harfbuzz would throttle text operations.
I suppose it is possible that we do not strictly need it as we currently 
create a
new harfbuzz "instance" each time we go to invoke layout but that
is something that at least theoretically could change.

The approach to synchronization is all from up-stream harfbuzz.
The harfbuzz mailing list might be the place to discuss that.
I'd expect it does work on AIX as a principal driver here is that
the IBM sponsored ICU project has deprecated its layout engine
and IBM/ICU are moving to harfbuzz so I'd be somewhat astonished
if they haven't yet tried it on AIX. Did you try just getting a copy
of the full hotspot library and running its configure on AIX to see if
harfbuzz can work out which options it wants there ? Obviously
I did not try that since I don't have AIX. Steven Loomis of IBM
who submitted the JEP should be able to help with a lot of this.

-phil.

On 12/8/15, 10:50 AM, Volker Simonis wrote:
> Hi,
>
> the integration of harfbuzz broke our AIX build because there's no
> implementation available for the hb_atomic macros in
> hb-atomic-private.hh. I've fixed that locally but still get a crash
> when running a simple AWT program (even with
> -Dsun.font.layoutengine=icu).
>
> I'm curretnly debugging the problem, but I have some general questions:
>
> 1. Do we really need the multi-threaded features of harfbuzz in OpenJDK?
>
> 2. Why does hurbuzz require these synchronization macros? From a first
> glance it doesn't seem to use multiple threads by itself. Does it have
> some global data structures which it needs to protect if harfbuzz is
> called from various threads?
>
> 3. Is there a way to test the hurfbuzz engine on a new platform? I saw
> the new test TestLayoutVsICU.java but it is marked as "manual" and it
> seems to require external fonts (at least some of which seem to be
> freely available). Could you please provide at least a minimal
> description on how this test can be run?
>
> 4. Is there a way to test that the implementation of the hb_atomic
> macros in hb-atomic-private.hh is correct (i.e. a way to stress
> harfbuzz from multiple threads)? I think this is important as I
> couldn't find a good description of the requirements for the atomic
> macros and on weak memory model architectures we should really get
> this right. For example there's no description of which fences are
> required around the various atomic operations. Getting this right
> across all platforms in the HotSpot (see
> hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp) is already hard
> enough so I'm a little concerned that we are now introducing similar
> primitives in the class library.
>
> Thank you and best regards,
> Volker


From philip.race at oracle.com  Wed Dec  9 18:34:16 2015
From: philip.race at oracle.com (Philip Race)
Date: Wed, 09 Dec 2015 10:34:16 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned
 write accesses
In-Reply-To: <56676501.9040104@oracle.com>
References: <CAKjRUT7Q25qjhqLMtSTYJMZrFRs9m2miegBHsfp38miqoHqpTg@mail.gmail.com>
	<5665F6D8.9070408@oracle.com>
	<CAKjRUT63xnexO4ovGAA0rN_JJ7vZU9sz2Je1szJ3FgGXxe8piA@mail.gmail.com>
	<CAKjRUT5hth+N87UnZT7NiFPQ-axPZUWJemsqvOsUfXcFptzmyA@mail.gmail.com>
	<56662EB7.2010307@oracle.com> <56676501.9040104@oracle.com>
Message-ID: <56687428.9010008@oracle.com>

looks fine although I wonder why you use & -4 instead of & ~3 ?

-phil.


On 12/8/15, 3:17 PM, Jim Graham wrote:
> With the submission of JDK-8144938 as a follow-on bug, this fix looks 
> fine now...
>
>             ...jim
>
> On 12/7/15 5:13 PM, Jim Graham wrote:
>> Do we make sure that the subpixel coords don't overflow an integer
>> somewhere?
>>
>>              ...jim
>>
>> On 12/7/15 1:52 PM, Laurent Bourg?s wrote:
>>> Moreover, it is concretely impossible as subpixel coords implies the
>>> maximum largest width is MAX_INT / 8 or 16 ...
>>>
>>> I should defintely add the same point filter as done in the
>>> DuctusRenderingEngine to filter both NaN and huge coords !
>>>
>>> Laurent
>>>
>>> Le 7 d?c. 2015 22:26, "Laurent Bourg?s" <bourges.laurent at gmail.com
>>> <mailto:bourges.laurent at gmail.com>> a ?crit :
>>>>
>>>> Jim,
>>>>
>>>> You are theoretical right !
>>>> However it needs a 2Gb row = px_bbox1 - px0 ! That's only possible if
>>>> you allocate an image with a single row (MAX_INT) and the shape
>>>> covers that full range !
>>>>
>>>> Do you really want me to fix that impossible case ? using 3L (and 
>>>> -4L).
>>>>
>>>> Laurent
>>>>
>>>> Le 7 d?c. 2015 22:15, "Jim Graham" <james.graham at oracle.com
>>>> <mailto:james.graham at oracle.com>> a ?crit :
>>>> >
>>>> > pos and needSize are longs.  px_bbox1 and px0 are positive ints 
>>>> with px_bbox1 known to be greater than px0 so the subtraction 
>>>> should not be able to overflow an int.  But, now that we are adding 
>>>> 3, is it possible for that calculation to overflow?  Would it be 
>>>> better to protect against that by using 3L (and -4L) even though 
>>>> these are theoretical issues? (The result of that calculation gets 
>>>> cast to long before adding it to pos anyway.)
>>>> >
>>>> >                         ...jim
>>>> >
>>>> >
>>>> > On 12/7/15 8:34 AM, Laurent Bourg?s wrote:
>>>> >>
>>>> >> Hi,
>>>> >>
>>>> >> Please review the following (critical) bug fix that ensures (4 
>>>> bytes)
>>>> >> aligned memory accesses (Unsafe) in MarlinCache:
>>>> >>
>>>> >> bug:https://bugs.openjdk.java.net/browse/JDK-8144828
>>>> >> 
>>>> webrev:http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144828.0/
>>>> >>
>>>> >> Changes:
>>>> >> - added MarlinConst.doCheckUnsafe (false by default) to manually 
>>>> check
>>>> >> addresses
>>>> >> - MarlinCache: align needed bytes in copyAARowNoRLE() as the same
>>>> >> off-heap block is also used by copyAARowRLE_WithBlockFlags() 
>>>> which store
>>>> >> RLE entries as integer:
>>>> >>
>>>> >> + // determine need array size:
>>>> >> + // for RLE encoding, position must be aligned to 4 bytes (int):
>>>> >> + // align - 1 = 3 so add +3 and round-off by mask ~3 = -4
>>>> >> + final long needSize = pos + ((px_bbox1 - px0 + 3) & -4);
>>>> >>
>>>> >> I did not tested on the sparc platform as I do not have one !
>>>> >> But it tested the patch on my linux 64 (intel).
>>>> >>
>>>> >> Best regards,
>>>> >> Laurent
>>>


From volker.simonis at gmail.com  Wed Dec  9 18:37:50 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 9 Dec 2015 19:37:50 +0100
Subject: [OpenJDK 2D-Dev] Question regarding the integration of harfbuzz
 (JEP 258)
In-Reply-To: <56685EA9.8020704@oracle.com>
References: <CA+3eh12NQnRhV85qNrB3Jqeu8Oq9-4utb0f+zXKsYgTNG1Qmcg@mail.gmail.com>
	<56685EA9.8020704@oracle.com>
Message-ID: <CA+3eh1181Q36L5faFEnVn_ptuECqZR+CHvgBB6MipGZyU3kW7w@mail.gmail.com>

Hi Phil,

thanks a lot for your answer. Please find my comments inline:

On Wed, Dec 9, 2015 at 6:02 PM, Philip Race <philip.race at oracle.com> wrote:
> Hi Volker,
>
> Running with ICU should stop harfbuzz use completely so if
> you are still seeing a crash, perhaps it is due to something else entirely.

Yes, it was indeed something completely different. It was "8145015:
jni_GetStringCritical asserts for empty strings"
(https://bugs.openjdk.java.net/browse/JDK-8145015) which I've opened
(and fixed :) today. The problem was that
sun.awt.X11.XlibWrapper.XSetLocaleModifiers() was called with an empty
string from sun.awt.X11.XToolkit.init() which crashed in the debug
build for the ISO8859-1 locale:

V  [libjvm.so+0xffffffff]  VMError::report_and_die(Thread*,const
char*,int,const char*,const char*,char*)+0x68
V  [libjvm.so+0xffffffff]  report_vm_error(const char*,int,const
char*,const char*,...)+0x8c
V  [libjvm.so+0xffffffff]  typeArrayOopDesc::char_at_addr(int) const+0x74
V  [libjvm.so+0xffffffff]  jni_GetStringCritical+0x2d4
C  [libjava.so+0xffffffff]  getString8859_1Chars+0x70
C  [libjava.so+0xffffffff]  JNU_GetStringPlatformChars+0xc4
C  [libawt_xawt.so+0xffffffff]
Java_sun_awt_X11_XlibWrapper_XSetLocaleModifiers+0x4c
j  sun.awt.X11.XlibWrapper.XSetLocaleModifiers(Ljava/lang/String;)Ljava/lang/String;+0
j  sun.awt.X11.XToolkit.init()V+9
j  sun.awt.X11.XToolkit.<init>()V+97

During debugging I also found out that "ISO-8859-1", which is the name
this locale has on Linux, isn't correctly detected as 'FAST_8859_1'
encoding. That's probably why nobody saw this error before. And that's
why it's always good to double check the code on AIX :)

I'll open a bug for the encoding problem on Linux tomorrow...

> Especially since a "simple AWT program" should not load layout anyway.
> There was a fair amount of new and changed code pushed recently ...
>
> Yes, we need to run harfbuzz in multiple concurrent threads in the JDK.
> A single threaded lock on harfbuzz would throttle text operations.
> I suppose it is possible that we do not strictly need it as we currently
> create a
> new harfbuzz "instance" each time we go to invoke layout but that
> is something that at least theoretically could change.
>
> The approach to synchronization is all from up-stream harfbuzz.
> The harfbuzz mailing list might be the place to discuss that.
> I'd expect it does work on AIX as a principal driver here is that
> the IBM sponsored ICU project has deprecated its layout engine
> and IBM/ICU are moving to harfbuzz so I'd be somewhat astonished
> if they haven't yet tried it on AIX. Did you try just getting a copy
> of the full hotspot library and running its configure on AIX to see if
> harfbuzz can work out which options it wants there ? Obviously
> I did not try that since I don't have AIX. Steven Loomis of IBM
> who submitted the JEP should be able to help with a lot of this.

That's strange, because I've looked at the up-stream harfbuzz project
and they definitely don't have the atomic instructions for AIX.

So either IBM completely dropped AIX or they are only using it from a
single thread or they haven't contributed their changes back to the
OpenJDK - which would be sad :( So it would be definitely interesting
to hear the actual internals from Steven :)

That said, I've now implemented the three atomics myself by using the
same compiler intrinsics like in the hotspot. I'll post a webrev
tomorrow...

Regards,
Volker

>
> -phil.
>
>
> On 12/8/15, 10:50 AM, Volker Simonis wrote:
>>
>> Hi,
>>
>> the integration of harfbuzz broke our AIX build because there's no
>> implementation available for the hb_atomic macros in
>> hb-atomic-private.hh. I've fixed that locally but still get a crash
>> when running a simple AWT program (even with
>> -Dsun.font.layoutengine=icu).
>>
>> I'm curretnly debugging the problem, but I have some general questions:
>>
>> 1. Do we really need the multi-threaded features of harfbuzz in OpenJDK?
>>
>> 2. Why does hurbuzz require these synchronization macros? From a first
>> glance it doesn't seem to use multiple threads by itself. Does it have
>> some global data structures which it needs to protect if harfbuzz is
>> called from various threads?
>>
>> 3. Is there a way to test the hurfbuzz engine on a new platform? I saw
>> the new test TestLayoutVsICU.java but it is marked as "manual" and it
>> seems to require external fonts (at least some of which seem to be
>> freely available). Could you please provide at least a minimal
>> description on how this test can be run?
>>
>> 4. Is there a way to test that the implementation of the hb_atomic
>> macros in hb-atomic-private.hh is correct (i.e. a way to stress
>> harfbuzz from multiple threads)? I think this is important as I
>> couldn't find a good description of the requirements for the atomic
>> macros and on weak memory model architectures we should really get
>> this right. For example there's no description of which fences are
>> required around the various atomic operations. Getting this right
>> across all platforms in the HotSpot (see
>> hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp) is already hard
>> enough so I'm a little concerned that we are now introducing similar
>> primitives in the class library.
>>
>> Thank you and best regards,
>> Volker


From philip.race at oracle.com  Wed Dec  9 18:49:14 2015
From: philip.race at oracle.com (Philip Race)
Date: Wed, 09 Dec 2015 10:49:14 -0800
Subject: [OpenJDK 2D-Dev] Question regarding the integration of harfbuzz
 (JEP 258)
In-Reply-To: <CA+3eh1181Q36L5faFEnVn_ptuECqZR+CHvgBB6MipGZyU3kW7w@mail.gmail.com>
References: <CA+3eh12NQnRhV85qNrB3Jqeu8Oq9-4utb0f+zXKsYgTNG1Qmcg@mail.gmail.com>
	<56685EA9.8020704@oracle.com>
	<CA+3eh1181Q36L5faFEnVn_ptuECqZR+CHvgBB6MipGZyU3kW7w@mail.gmail.com>
Message-ID: <566877AA.40208@oracle.com>

Hmm. Should JEP 254 really have " removed the handling of empty strings 
from jni_GetStringCritical()."
without tracking down uses and updating them ?

I didn't mean IBM already ship harfbuzz in their JDK but I thought
they were already using it in some other IBM products.

-phil.

On 12/9/15, 10:37 AM, Volker Simonis wrote:
> Hi Phil,
>
> thanks a lot for your answer. Please find my comments inline:
>
> On Wed, Dec 9, 2015 at 6:02 PM, Philip Race<philip.race at oracle.com>  wrote:
>> Hi Volker,
>>
>> Running with ICU should stop harfbuzz use completely so if
>> you are still seeing a crash, perhaps it is due to something else entirely.
> Yes, it was indeed something completely different. It was "8145015:
> jni_GetStringCritical asserts for empty strings"
> (https://bugs.openjdk.java.net/browse/JDK-8145015) which I've opened
> (and fixed :) today. The problem was that
> sun.awt.X11.XlibWrapper.XSetLocaleModifiers() was called with an empty
> string from sun.awt.X11.XToolkit.init() which crashed in the debug
> build for the ISO8859-1 locale:
>
> V  [libjvm.so+0xffffffff]  VMError::report_and_die(Thread*,const
> char*,int,const char*,const char*,char*)+0x68
> V  [libjvm.so+0xffffffff]  report_vm_error(const char*,int,const
> char*,const char*,...)+0x8c
> V  [libjvm.so+0xffffffff]  typeArrayOopDesc::char_at_addr(int) const+0x74
> V  [libjvm.so+0xffffffff]  jni_GetStringCritical+0x2d4
> C  [libjava.so+0xffffffff]  getString8859_1Chars+0x70
> C  [libjava.so+0xffffffff]  JNU_GetStringPlatformChars+0xc4
> C  [libawt_xawt.so+0xffffffff]
> Java_sun_awt_X11_XlibWrapper_XSetLocaleModifiers+0x4c
> j  sun.awt.X11.XlibWrapper.XSetLocaleModifiers(Ljava/lang/String;)Ljava/lang/String;+0
> j  sun.awt.X11.XToolkit.init()V+9
> j  sun.awt.X11.XToolkit.<init>()V+97
>
> During debugging I also found out that "ISO-8859-1", which is the name
> this locale has on Linux, isn't correctly detected as 'FAST_8859_1'
> encoding. That's probably why nobody saw this error before. And that's
> why it's always good to double check the code on AIX :)
>
> I'll open a bug for the encoding problem on Linux tomorrow...
>
>> Especially since a "simple AWT program" should not load layout anyway.
>> There was a fair amount of new and changed code pushed recently ...
>>
>> Yes, we need to run harfbuzz in multiple concurrent threads in the JDK.
>> A single threaded lock on harfbuzz would throttle text operations.
>> I suppose it is possible that we do not strictly need it as we currently
>> create a
>> new harfbuzz "instance" each time we go to invoke layout but that
>> is something that at least theoretically could change.
>>
>> The approach to synchronization is all from up-stream harfbuzz.
>> The harfbuzz mailing list might be the place to discuss that.
>> I'd expect it does work on AIX as a principal driver here is that
>> the IBM sponsored ICU project has deprecated its layout engine
>> and IBM/ICU are moving to harfbuzz so I'd be somewhat astonished
>> if they haven't yet tried it on AIX. Did you try just getting a copy
>> of the full hotspot library and running its configure on AIX to see if
>> harfbuzz can work out which options it wants there ? Obviously
>> I did not try that since I don't have AIX. Steven Loomis of IBM
>> who submitted the JEP should be able to help with a lot of this.
> That's strange, because I've looked at the up-stream harfbuzz project
> and they definitely don't have the atomic instructions for AIX.
>
> So either IBM completely dropped AIX or they are only using it from a
> single thread or they haven't contributed their changes back to the
> OpenJDK - which would be sad :( So it would be definitely interesting
> to hear the actual internals from Steven :)
>
> That said, I've now implemented the three atomics myself by using the
> same compiler intrinsics like in the hotspot. I'll post a webrev
> tomorrow...
>
> Regards,
> Volker
>
>> -phil.
>>
>>
>> On 12/8/15, 10:50 AM, Volker Simonis wrote:
>>> Hi,
>>>
>>> the integration of harfbuzz broke our AIX build because there's no
>>> implementation available for the hb_atomic macros in
>>> hb-atomic-private.hh. I've fixed that locally but still get a crash
>>> when running a simple AWT program (even with
>>> -Dsun.font.layoutengine=icu).
>>>
>>> I'm curretnly debugging the problem, but I have some general questions:
>>>
>>> 1. Do we really need the multi-threaded features of harfbuzz in OpenJDK?
>>>
>>> 2. Why does hurbuzz require these synchronization macros? From a first
>>> glance it doesn't seem to use multiple threads by itself. Does it have
>>> some global data structures which it needs to protect if harfbuzz is
>>> called from various threads?
>>>
>>> 3. Is there a way to test the hurfbuzz engine on a new platform? I saw
>>> the new test TestLayoutVsICU.java but it is marked as "manual" and it
>>> seems to require external fonts (at least some of which seem to be
>>> freely available). Could you please provide at least a minimal
>>> description on how this test can be run?
>>>
>>> 4. Is there a way to test that the implementation of the hb_atomic
>>> macros in hb-atomic-private.hh is correct (i.e. a way to stress
>>> harfbuzz from multiple threads)? I think this is important as I
>>> couldn't find a good description of the requirements for the atomic
>>> macros and on weak memory model architectures we should really get
>>> this right. For example there's no description of which fences are
>>> required around the various atomic operations. Getting this right
>>> across all platforms in the HotSpot (see
>>> hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp) is already hard
>>> enough so I'm a little concerned that we are now introducing similar
>>> primitives in the class library.
>>>
>>> Thank you and best regards,
>>> Volker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151209/54301120/attachment.html>

From bourges.laurent at gmail.com  Wed Dec  9 18:54:37 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 9 Dec 2015 19:54:37 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned
 write accesses
In-Reply-To: <56687428.9010008@oracle.com>
References: <CAKjRUT7Q25qjhqLMtSTYJMZrFRs9m2miegBHsfp38miqoHqpTg@mail.gmail.com>
	<5665F6D8.9070408@oracle.com>
	<CAKjRUT63xnexO4ovGAA0rN_JJ7vZU9sz2Je1szJ3FgGXxe8piA@mail.gmail.com>
	<CAKjRUT5hth+N87UnZT7NiFPQ-axPZUWJemsqvOsUfXcFptzmyA@mail.gmail.com>
	<56662EB7.2010307@oracle.com> <56676501.9040104@oracle.com>
	<56687428.9010008@oracle.com>
Message-ID: <CAKjRUT6npZqHVPbm9OrndjRfJjikkxme53Fqr_2q1pu-may7nA@mail.gmail.com>

Phil,

To be short: ~3= -4.

You are right, javac could have done that computation for me !

Laurent

Le 9 d?c. 2015 19:34, "Philip Race" <philip.race at oracle.com> a ?crit :
>
> looks fine although I wonder why you use & -4 instead of & ~3 ?
>
> -phil.
>
>
>
> On 12/8/15, 3:17 PM, Jim Graham wrote:
>>
>> With the submission of JDK-8144938 as a follow-on bug, this fix looks
fine now...
>>
>>             ...jim
>>
>> On 12/7/15 5:13 PM, Jim Graham wrote:
>>>
>>> Do we make sure that the subpixel coords don't overflow an integer
>>> somewhere?
>>>
>>>              ...jim
>>>
>>> On 12/7/15 1:52 PM, Laurent Bourg?s wrote:
>>>>
>>>> Moreover, it is concretely impossible as subpixel coords implies the
>>>> maximum largest width is MAX_INT / 8 or 16 ...
>>>>
>>>> I should defintely add the same point filter as done in the
>>>> DuctusRenderingEngine to filter both NaN and huge coords !
>>>>
>>>> Laurent
>>>>
>>>> Le 7 d?c. 2015 22:26, "Laurent Bourg?s" <bourges.laurent at gmail.com
>>>> <mailto:bourges.laurent at gmail.com>> a ?crit :
>>>>>
>>>>>
>>>>> Jim,
>>>>>
>>>>> You are theoretical right !
>>>>> However it needs a 2Gb row = px_bbox1 - px0 ! That's only possible if
>>>>> you allocate an image with a single row (MAX_INT) and the shape
>>>>> covers that full range !
>>>>>
>>>>> Do you really want me to fix that impossible case ? using 3L (and
-4L).
>>>>>
>>>>> Laurent
>>>>>
>>>>> Le 7 d?c. 2015 22:15, "Jim Graham" <james.graham at oracle.com
>>>>> <mailto:james.graham at oracle.com>> a ?crit :
>>>>> >
>>>>> > pos and needSize are longs.  px_bbox1 and px0 are positive ints
with px_bbox1 known to be greater than px0 so the subtraction should not be
able to overflow an int.  But, now that we are adding 3, is it possible for
that calculation to overflow?  Would it be better to protect against that
by using 3L (and -4L) even though these are theoretical issues? (The result
of that calculation gets cast to long before adding it to pos anyway.)
>>>>> >
>>>>> >                         ...jim
>>>>> >
>>>>> >
>>>>> > On 12/7/15 8:34 AM, Laurent Bourg?s wrote:
>>>>> >>
>>>>> >> Hi,
>>>>> >>
>>>>> >> Please review the following (critical) bug fix that ensures (4
bytes)
>>>>> >> aligned memory accesses (Unsafe) in MarlinCache:
>>>>> >>
>>>>> >> bug:https://bugs.openjdk.java.net/browse/JDK-8144828
>>>>> >> webrev:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144828.0/
>>>>> >>
>>>>> >> Changes:
>>>>> >> - added MarlinConst.doCheckUnsafe (false by default) to manually
check
>>>>> >> addresses
>>>>> >> - MarlinCache: align needed bytes in copyAARowNoRLE() as the same
>>>>> >> off-heap block is also used by copyAARowRLE_WithBlockFlags() which
store
>>>>> >> RLE entries as integer:
>>>>> >>
>>>>> >> + // determine need array size:
>>>>> >> + // for RLE encoding, position must be aligned to 4 bytes (int):
>>>>> >> + // align - 1 = 3 so add +3 and round-off by mask ~3 = -4
>>>>> >> + final long needSize = pos + ((px_bbox1 - px0 + 3) & -4);
>>>>> >>
>>>>> >> I did not tested on the sparc platform as I do not have one !
>>>>> >> But it tested the patch on my linux 64 (intel).
>>>>> >>
>>>>> >> Best regards,
>>>>> >> Laurent
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151209/4845694b/attachment.html>

From james.graham at oracle.com  Wed Dec  9 21:31:03 2015
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 9 Dec 2015 13:31:03 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <CAKjRUT7qLSdYaBvN5Ci6HouP06iUJvefbGAYGikJF_Z4s4kNrg@mail.gmail.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
	<566219C4.303@oracle.com> <56621A48.7020406@oracle.com>
	<56663D94.6040304@oracle.com>
	<CAKjRUT7u+wm5x5eyG5o-3krMWtNwD3f_jc40zos4Gn0-CpTz9w@mail.gmail.com>
	<566763C2.7070800@oracle.com> <56682555.9020809@oracle.com>
	<CAKjRUT7qLSdYaBvN5Ci6HouP06iUJvefbGAYGikJF_Z4s4kNrg@mail.gmail.com>
Message-ID: <56689D97.3070406@oracle.com>

Hi Laurent,

One clarification - there are levels of automation.

On 12/9/15 6:35 AM, Laurent Bourg?s wrote:
> Agreed it is possible but then the bug JDK-8144446
> <https://bugs.openjdk.java.net/browse/JDK-8144446> becomes invalid.

Prior to this fix, jtreg wouldn't even see the test since it did not 
have any tags in it at all.  Adding tags of "some sort" makes it able to 
be run by the test mechanism, which I call "automated".  Right now, 
nobody who runs jtreg will run this test no matter what command line 
arguments they use with the tool.

Once jtreg recognizes a test there are variations that let it decide 
when/if to run it.  It has 3 main modes (related to the /manual tag):

no options - all tests are run, both manual and automatic
-a - ignore all /manual tests
-m - run only /manual tests

-a primarily means "there is no human here to provide interaction", but 
a few non-manual tests take a long time.

On the other hand, I just did a test run of all tests (with -a) in 
sun/java2d and the total time was so long that the 30 seconds wasn't 
that noticeable.  On the other hand, there were a lot of tests run so 
the long time was less because a lot of tests take a long time than it 
was about the fact that a lot of conditions were tested in that time. 
For the record, the next longest test in that part of the repo takes 8 
seconds, so this new test is almost 5 times longer than any existing 
java2d test.  Only the longest 4 tests took more than 5 seconds.

I did find a test with "@ignore slow test" in another part of the repo 
and I ran it and it took 8 seconds as well, so somebody out there 
considers 8 seconds to be too long to run under ordinary circumstances.

I tend to want to push hard on making tests be faster and leaner.  I see 
so many bug fixes come in with automated tests that only have to run a 
single method and see if it returns the right answer and yet somehow the 
test needs to launch a Frame and wait for it to open and then do a 
screen readback - when a simple render to a BufferedImage would take 
1/100th the time.

I'll withdraw my suggestion to make this one /manual, but it would be 
nice if it could do its work in just a few seconds instead...

			...jim


From bourges.laurent at gmail.com  Wed Dec  9 21:38:23 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 9 Dec 2015 22:38:23 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144445: Maximum size checking in Marlin
 ArrayCache utility methods is not optimal
In-Reply-To: <56662E11.8080408@oracle.com>
References: <CAKjRUT7=puzVxKiqEGoCae_QCcw6Nu-HBZa6LvmB=Uqcf0mcyA@mail.gmail.com>
	<56621E1A.1080602@oracle.com>
	<CAKjRUT4B2g+FPZKYHUfXipbBhQiAy9PFxEN2v2zvntb1LmVWGg@mail.gmail.com>
	<56662E11.8080408@oracle.com>
Message-ID: <CAKjRUT49Sg7vvn1KtMUxx25ksmjRQ0CYcFT1auSVy3F9+bt3-A@mail.gmail.com>

Hi Jim,

I took me some time to understand your detailled analysis and make a new
webrev:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144445.2/

I think I adopted all your change proposals, see below:

In looking this over again I notice that really the exceptions are only
> thrown on "out of range" needSize values and they are probably always
> thrown in that case, but sometimes we only discover those range issues if
> other things fail and many of the tests that lead to getting to that
> statement may or may not operate correctly depending on whether they are
> dealing with a valid needSize (for instance testing against "< needSize"
> when needSize might be negative, etc.).  It makes verifying this code much
> more difficult due to having to deal with cases where multiple variables
> might be out of range when they are computed or compared against each
> other.  To that end, it might be more straightforward to simply test
> needSize at the top and then the rest of the function can know it is
> dealing with a proper value for needSize and only has to worry about
> returning a non-overflowing number.  Knowing that needSize is a valid
> number makes any computations with it or compares against it have fewer
> "failure conditions" to note and vet.
>

I followed your approach and I agree it is more clear.

>
> For example:
>
> first function:
>
> 185-189 move to the top of the function and only test needSize and then
> later on line 177 we capture any overflow since we know that needSize
> cannot be negative as well.  180,182 are then sufficient to make sure that
> the value calculated in that case will be >= needSize.
>

Fixed.


> second function:
>
> 215-220 also move to the top of that function and 214 (if it compares size
> in both cases) is sufficient to make sure we are returning a value >=
> needSize in all cases.  As it stands 210 and 212 could be computing random
> values and the tests at 214 and later are no longer complicated by having
> to consider the case that needSize itself is wrong - they only have to deal
> with whether the returned size bumped out of range.
>

Fixed.


> general note:
>
> Also, "(longval < 0L || longval > MAX_INT)" can be calculated as
> "((longval >> 31) != 0)".
>

Thanks for the tip: I use it now.


> I could also check size < 0L if you want but it is only possible if
>> curSize < 0 (that should never happen) !
>>
>
> That may be true at line 209, but then you test it against needSize and do
> more calculations where the new value of size depends only on needSize and
> so its dependence on curSize no longer offers any protection.  At 214 you
> might not be able to assert that size>=0 any more as a result.
>
>   That works.  I was thinking more along the lines of this which is more
>> straightforward:
>>
>
> try {
>     do test;
>     throw new RuntimeException("AIOBException not thrown");
> } catch (AIOBException e) (
>     return;
> } catch (Throwable t) {
>     throw new RuntimeException("Wrong exception (not AIOB) thrown", t);
> }
>

Fixed.

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151209/39ba7e29/attachment.html>

From james.graham at oracle.com  Wed Dec  9 21:39:07 2015
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 9 Dec 2015 13:39:07 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144828: Marlin renderer causes unaligned
 write accesses
In-Reply-To: <56687428.9010008@oracle.com>
References: <CAKjRUT7Q25qjhqLMtSTYJMZrFRs9m2miegBHsfp38miqoHqpTg@mail.gmail.com>
	<5665F6D8.9070408@oracle.com>
	<CAKjRUT63xnexO4ovGAA0rN_JJ7vZU9sz2Je1szJ3FgGXxe8piA@mail.gmail.com>
	<CAKjRUT5hth+N87UnZT7NiFPQ-axPZUWJemsqvOsUfXcFptzmyA@mail.gmail.com>
	<56662EB7.2010307@oracle.com> <56676501.9040104@oracle.com>
	<56687428.9010008@oracle.com>
Message-ID: <56689F7B.8040609@oracle.com>

I noticed that too, but they are equivalent.  I think it is much more 
common to use ~3, but I didn't wan to hold this up for a syntax nit...

			...jim

On 12/9/15 10:34 AM, Philip Race wrote:
> looks fine although I wonder why you use & -4 instead of & ~3 ?
>
> -phil.
>
>
> On 12/8/15, 3:17 PM, Jim Graham wrote:
>> With the submission of JDK-8144938 as a follow-on bug, this fix looks
>> fine now...
>>
>>             ...jim
>>
>> On 12/7/15 5:13 PM, Jim Graham wrote:
>>> Do we make sure that the subpixel coords don't overflow an integer
>>> somewhere?
>>>
>>>              ...jim
>>>
>>> On 12/7/15 1:52 PM, Laurent Bourg?s wrote:
>>>> Moreover, it is concretely impossible as subpixel coords implies the
>>>> maximum largest width is MAX_INT / 8 or 16 ...
>>>>
>>>> I should defintely add the same point filter as done in the
>>>> DuctusRenderingEngine to filter both NaN and huge coords !
>>>>
>>>> Laurent
>>>>
>>>> Le 7 d?c. 2015 22:26, "Laurent Bourg?s" <bourges.laurent at gmail.com
>>>> <mailto:bourges.laurent at gmail.com>> a ?crit :
>>>>>
>>>>> Jim,
>>>>>
>>>>> You are theoretical right !
>>>>> However it needs a 2Gb row = px_bbox1 - px0 ! That's only possible if
>>>>> you allocate an image with a single row (MAX_INT) and the shape
>>>>> covers that full range !
>>>>>
>>>>> Do you really want me to fix that impossible case ? using 3L (and
>>>>> -4L).
>>>>>
>>>>> Laurent
>>>>>
>>>>> Le 7 d?c. 2015 22:15, "Jim Graham" <james.graham at oracle.com
>>>>> <mailto:james.graham at oracle.com>> a ?crit :
>>>>> >
>>>>> > pos and needSize are longs.  px_bbox1 and px0 are positive intswith px_bbox1 known to be greater than px0 so the subtraction
>>>>> should not be able to overflow an int.  But, now that we are adding
>>>>> 3, is it possible for that calculation to overflow?  Would it be
>>>>> better to protect against that by using 3L (and -4L) even though
>>>>> these are theoretical issues? (The result of that calculation gets
>>>>> cast to long before adding it to pos anyway.)
>>>>> >
>>>>> >                         ...jim
>>>>> >
>>>>> >
>>>>> > On 12/7/15 8:34 AM, Laurent Bourg?s wrote:
>>>>> >>
>>>>> >> Hi,
>>>>> >>
>>>>> >> Please review the following (critical) bug fix that ensures (4bytes)
>>>>> >> aligned memory accesses (Unsafe) in MarlinCache:
>>>>> >>
>>>>> >> bug:https://bugs.openjdk.java.net/browse/JDK-8144828
>>>>> >>webrev:http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144828.0/
>>>>> >>
>>>>> >> Changes:
>>>>> >> - added MarlinConst.doCheckUnsafe (false by default) to manuallycheck
>>>>> >> addresses
>>>>> >> - MarlinCache: align needed bytes in copyAARowNoRLE() as the same
>>>>> >> off-heap block is also used by copyAARowRLE_WithBlockFlags()which store
>>>>> >> RLE entries as integer:
>>>>> >>
>>>>> >> + // determine need array size:
>>>>> >> + // for RLE encoding, position must be aligned to 4 bytes (int):
>>>>> >> + // align - 1 = 3 so add +3 and round-off by mask ~3 = -4
>>>>> >> + final long needSize = pos + ((px_bbox1 - px0 + 3) & -4);
>>>>> >>
>>>>> >> I did not tested on the sparc platform as I do not have one !
>>>>> >> But it tested the patch on my linux 64 (intel).
>>>>> >>
>>>>> >> Best regards,
>>>>> >> Laurent
>>>>


From james.graham at oracle.com  Wed Dec  9 22:08:09 2015
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 9 Dec 2015 14:08:09 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144445: Maximum size checking in Marlin
 ArrayCache utility methods is not optimal
In-Reply-To: <CAKjRUT49Sg7vvn1KtMUxx25ksmjRQ0CYcFT1auSVy3F9+bt3-A@mail.gmail.com>
References: <CAKjRUT7=puzVxKiqEGoCae_QCcw6Nu-HBZa6LvmB=Uqcf0mcyA@mail.gmail.com>
	<56621E1A.1080602@oracle.com>
	<CAKjRUT4B2g+FPZKYHUfXipbBhQiAy9PFxEN2v2zvntb1LmVWGg@mail.gmail.com>
	<56662E11.8080408@oracle.com>
	<CAKjRUT49Sg7vvn1KtMUxx25ksmjRQ0CYcFT1auSVy3F9+bt3-A@mail.gmail.com>
Message-ID: <5668A649.1030403@oracle.com>

Looks good.

And verified that the test fails before the fix and passes after...

			...jim

On 12/9/15 1:38 PM, Laurent Bourg?s wrote:
> Hi Jim,
>
> I took me some time to understand your detailled analysis and make a new
> webrev:
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144445.2/
>
> I think I adopted all your change proposals, see below:
>
>     In looking this over again I notice that really the exceptions are
>     only thrown on "out of range" needSize values and they are probably
>     always thrown in that case, but sometimes we only discover those
>     range issues if other things fail and many of the tests that lead to
>     getting to that statement may or may not operate correctly depending
>     on whether they are dealing with a valid needSize (for instance
>     testing against "< needSize" when needSize might be negative,
>     etc.).  It makes verifying this code much more difficult due to
>     having to deal with cases where multiple variables might be out of
>     range when they are computed or compared against each other.  To
>     that end, it might be more straightforward to simply test needSize
>     at the top and then the rest of the function can know it is dealing
>     with a proper value for needSize and only has to worry about
>     returning a non-overflowing number.  Knowing that needSize is a
>     valid number makes any computations with it or compares against it
>     have fewer "failure conditions" to note and vet.
>
>
> I followed your approach and I agree it is more clear.
>
>
>     For example:
>
>     first function:
>
>     185-189 move to the top of the function and only test needSize and
>     then later on line 177 we capture any overflow since we know that
>     needSize cannot be negative as well.  180,182 are then sufficient to
>     make sure that the value calculated in that case will be >= needSize.
>
>
> Fixed.
>
>     second function:
>
>     215-220 also move to the top of that function and 214 (if it
>     compares size in both cases) is sufficient to make sure we are
>     returning a value >= needSize in all cases.  As it stands 210 and
>     212 could be computing random values and the tests at 214 and later
>     are no longer complicated by having to consider the case that
>     needSize itself is wrong - they only have to deal with whether the
>     returned size bumped out of range.
>
>
> Fixed.
>
>     general note:
>
>     Also, "(longval < 0L || longval > MAX_INT)" can be calculated as
>     "((longval >> 31) != 0)".
>
>
> Thanks for the tip: I use it now.
>
>         I could also check size < 0L if you want but it is only possible if
>         curSize < 0 (that should never happen) !
>
>
>     That may be true at line 209, but then you test it against needSize
>     and do more calculations where the new value of size depends only on
>     needSize and so its dependence on curSize no longer offers any
>     protection.  At 214 you might not be able to assert that size>=0 any
>     more as a result.
>
>            That works.  I was thinking more along the lines of this
>         which is more straightforward:
>
>
>     try {
>          do test;
>          throw new RuntimeException("AIOBException not thrown");
>     } catch (AIOBException e) (
>          return;
>     } catch (Throwable t) {
>          throw new RuntimeException("Wrong exception (not AIOB) thrown", t);
>     }
>
>
> Fixed.
>
> Cheers,
> Laurent


From bourges.laurent at gmail.com  Wed Dec  9 22:25:16 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 9 Dec 2015 23:25:16 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <56689D97.3070406@oracle.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
	<566219C4.303@oracle.com> <56621A48.7020406@oracle.com>
	<56663D94.6040304@oracle.com>
	<CAKjRUT7u+wm5x5eyG5o-3krMWtNwD3f_jc40zos4Gn0-CpTz9w@mail.gmail.com>
	<566763C2.7070800@oracle.com> <56682555.9020809@oracle.com>
	<CAKjRUT7qLSdYaBvN5Ci6HouP06iUJvefbGAYGikJF_Z4s4kNrg@mail.gmail.com>
	<56689D97.3070406@oracle.com>
Message-ID: <CAKjRUT6wdiuSakCpLt8dtKX_upfYUY76Mrb+a7T-WdZF332KFg@mail.gmail.com>

Jim,

Thanks for explaining me the different jtreg modes (newbie) !

I tried disabling few long tests (using dashes) that are less critical (no
failure expected, just insane rendering work):
            test(0.1f, false, 0);
            test(0.1f, true, 7f);

Doing so, I detected a new issue in the Renderer.dispose() when the
addLine() fails due to the AIOB (2GB off-heap overflow):
the range buckets_minY/maxY are not properly set, normally by
endRendering(), and the edgeBucket arrays are not properly zero-filled !

I will work on this issue ASAP and propose a fix within the same bug.

Maybe we should defer this fix as I agree it can be made faster ~ 12s now
vs 52s before on my laptop.

Laurent

2015-12-09 22:31 GMT+01:00 Jim Graham <james.graham at oracle.com>:

> Hi Laurent,
>
> One clarification - there are levels of automation.
>
> On 12/9/15 6:35 AM, Laurent Bourg?s wrote:
>
>> Agreed it is possible but then the bug JDK-8144446
>> <https://bugs.openjdk.java.net/browse/JDK-8144446> becomes invalid.
>>
>
> Prior to this fix, jtreg wouldn't even see the test since it did not have
> any tags in it at all.  Adding tags of "some sort" makes it able to be run
> by the test mechanism, which I call "automated".  Right now, nobody who
> runs jtreg will run this test no matter what command line arguments they
> use with the tool.
>
> Once jtreg recognizes a test there are variations that let it decide
> when/if to run it.  It has 3 main modes (related to the /manual tag):
>
> no options - all tests are run, both manual and automatic
> -a - ignore all /manual tests
> -m - run only /manual tests
>
> -a primarily means "there is no human here to provide interaction", but a
> few non-manual tests take a long time.
>
> On the other hand, I just did a test run of all tests (with -a) in
> sun/java2d and the total time was so long that the 30 seconds wasn't that
> noticeable.  On the other hand, there were a lot of tests run so the long
> time was less because a lot of tests take a long time than it was about the
> fact that a lot of conditions were tested in that time. For the record, the
> next longest test in that part of the repo takes 8 seconds, so this new
> test is almost 5 times longer than any existing java2d test.  Only the
> longest 4 tests took more than 5 seconds.
>
> I did find a test with "@ignore slow test" in another part of the repo and
> I ran it and it took 8 seconds as well, so somebody out there considers 8
> seconds to be too long to run under ordinary circumstances.
>
> I tend to want to push hard on making tests be faster and leaner.  I see
> so many bug fixes come in with automated tests that only have to run a
> single method and see if it returns the right answer and yet somehow the
> test needs to launch a Frame and wait for it to open and then do a screen
> readback - when a simple render to a BufferedImage would take 1/100th the
> time.
>
> I'll withdraw my suggestion to make this one /manual, but it would be nice
> if it could do its work in just a few seconds instead...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151209/59d36189/attachment.html>

From james.graham at oracle.com  Wed Dec  9 22:31:59 2015
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 9 Dec 2015 14:31:59 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <CAKjRUT6wdiuSakCpLt8dtKX_upfYUY76Mrb+a7T-WdZF332KFg@mail.gmail.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
	<566219C4.303@oracle.com> <56621A48.7020406@oracle.com>
	<56663D94.6040304@oracle.com>
	<CAKjRUT7u+wm5x5eyG5o-3krMWtNwD3f_jc40zos4Gn0-CpTz9w@mail.gmail.com>
	<566763C2.7070800@oracle.com> <56682555.9020809@oracle.com>
	<CAKjRUT7qLSdYaBvN5Ci6HouP06iUJvefbGAYGikJF_Z4s4kNrg@mail.gmail.com>
	<56689D97.3070406@oracle.com>
	<CAKjRUT6wdiuSakCpLt8dtKX_upfYUY76Mrb+a7T-WdZF332KFg@mail.gmail.com>
Message-ID: <5668ABDF.7030002@oracle.com>

Hi Laurent,

That sounds good.  I'm all for fast tests!  ;)

We might want to fix them in separate bugs, though.  If the new mods to 
the test case lead to failures, then we should integrate them after we 
fix the underlying problems, though, to prevent testing failures that 
might block an integration...

			...jim

On 12/9/15 2:25 PM, Laurent Bourg?s wrote:
> Jim,
>
> Thanks for explaining me the different jtreg modes (newbie) !
>
> I tried disabling few long tests (using dashes) that are less critical
> (no failure expected, just insane rendering work):
>              test(0.1f, false, 0);
>              test(0.1f, true, 7f);
>
> Doing so, I detected a new issue in the Renderer.dispose() when the
> addLine() fails due to the AIOB (2GB off-heap overflow):
> the range buckets_minY/maxY are not properly set, normally by
> endRendering(), and the edgeBucket arrays are not properly zero-filled !
>
> I will work on this issue ASAP and propose a fix within the same bug.
>
> Maybe we should defer this fix as I agree it can be made faster ~ 12s
> now vs 52s before on my laptop.
>
> Laurent
>
> 2015-12-09 22:31 GMT+01:00 Jim Graham <james.graham at oracle.com
> <mailto:james.graham at oracle.com>>:
>
>     Hi Laurent,
>
>     One clarification - there are levels of automation.
>
>     On 12/9/15 6:35 AM, Laurent Bourg?s wrote:
>
>         Agreed it is possible but then the bug JDK-8144446
>         <https://bugs.openjdk.java.net/browse/JDK-8144446> becomes invalid.
>
>
>     Prior to this fix, jtreg wouldn't even see the test since it did not
>     have any tags in it at all.  Adding tags of "some sort" makes it
>     able to be run by the test mechanism, which I call "automated".
>     Right now, nobody who runs jtreg will run this test no matter what
>     command line arguments they use with the tool.
>
>     Once jtreg recognizes a test there are variations that let it decide
>     when/if to run it.  It has 3 main modes (related to the /manual tag):
>
>     no options - all tests are run, both manual and automatic
>     -a - ignore all /manual tests
>     -m - run only /manual tests
>
>     -a primarily means "there is no human here to provide interaction",
>     but a few non-manual tests take a long time.
>
>     On the other hand, I just did a test run of all tests (with -a) in
>     sun/java2d and the total time was so long that the 30 seconds wasn't
>     that noticeable.  On the other hand, there were a lot of tests run
>     so the long time was less because a lot of tests take a long time
>     than it was about the fact that a lot of conditions were tested in
>     that time. For the record, the next longest test in that part of the
>     repo takes 8 seconds, so this new test is almost 5 times longer than
>     any existing java2d test.  Only the longest 4 tests took more than 5
>     seconds.
>
>     I did find a test with "@ignore slow test" in another part of the
>     repo and I ran it and it took 8 seconds as well, so somebody out
>     there considers 8 seconds to be too long to run under ordinary
>     circumstances.
>
>     I tend to want to push hard on making tests be faster and leaner.  I
>     see so many bug fixes come in with automated tests that only have to
>     run a single method and see if it returns the right answer and yet
>     somehow the test needs to launch a Frame and wait for it to open and
>     then do a screen readback - when a simple render to a BufferedImage
>     would take 1/100th the time.
>
>     I'll withdraw my suggestion to make this one /manual, but it would
>     be nice if it could do its work in just a few seconds instead...
>


From jennifer.godinez at oracle.com  Wed Dec  9 22:58:02 2015
From: jennifer.godinez at oracle.com (Jennifer Godinez)
Date: Wed, 09 Dec 2015 14:58:02 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8137106: EUDC (End User Defined
 Characters) are not displayed on Windows with Java 8u60+
In-Reply-To: <5665C9D4.6080906@oracle.com>
References: <56620841.1010909@oracle.com>
	<5665B057.3020803@oracle.com>	<5665C030.1080702@oracle.com>
	<5665C9D4.6080906@oracle.com>
Message-ID: <5668B1FA.1080505@oracle.com>

Looks good.

Jennifer
On 12/07/2015 10:03 AM, Phil Race wrote:
> Fixed : http://cr.openjdk.java.net/~prr/8137106.1/
>
> -phil.
>
> On 12/07/2015 09:21 AM, Philip Race wrote:
>> Yeah .. that should have been true. I'll upload a fixed patch.
>>
>> -phil.
>>
>> On 12/7/15, 8:14 AM, Sergey Bylokhov wrote:
>>> Hi, Phil.
>>> It is unclear why default implementation of TrueTypeFont.open() call 
>>> open(usePool=false)? also useFilePool vs usePool.
>>>
>>> On 05.12.15 0:40, Phil Race wrote:
>>>> https://bugs.openjdk.java.net/browse/JDK-8137106
>>>> http://cr.openjdk.java.net/~prr/8137106/index.html
>>>>
>>>> See the bug report for a long evaluation but here is the short 
>>>> version.
>>>> In order to prevent recursive creation of the FontManager we need to
>>>> have loading the construction of the TrueTypeFont representing the 
>>>> EUDC
>>>> font avoid referencing the FontManager. This is done by locally 
>>>> opening
>>>> and closing the font file in just that case.
>>>>
>>>> This fix is designed to be low-risk as it needs backporting.
>>>>
>>>> A test for this is not practical as it requires a user to install an
>>>> EUDC font which
>>>> requires special steps different than installing a normal font.
>>>> Manual verification will be required.
>>>>
>>>> -phil.
>>>
>>>
>



From bourges.laurent at gmail.com  Wed Dec  9 23:10:42 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 10 Dec 2015 00:10:42 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <5668ABDF.7030002@oracle.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
	<566219C4.303@oracle.com> <56621A48.7020406@oracle.com>
	<56663D94.6040304@oracle.com>
	<CAKjRUT7u+wm5x5eyG5o-3krMWtNwD3f_jc40zos4Gn0-CpTz9w@mail.gmail.com>
	<566763C2.7070800@oracle.com> <56682555.9020809@oracle.com>
	<CAKjRUT7qLSdYaBvN5Ci6HouP06iUJvefbGAYGikJF_Z4s4kNrg@mail.gmail.com>
	<56689D97.3070406@oracle.com>
	<CAKjRUT6wdiuSakCpLt8dtKX_upfYUY76Mrb+a7T-WdZF332KFg@mail.gmail.com>
	<5668ABDF.7030002@oracle.com>
Message-ID: <CAKjRUT6dCt7tsONipDatV=_3ANHO_7WsZcENN0JJQjDOYGAJ+g@mail.gmail.com>

Jim,

My last chance for tonight !

Here is another webrev that disables two long tests (dasher) in CrashTest
but fixes a state cleanup bug in Renderer (doChecks=true):
http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.2/

Note: the modified CrashTest detected this bug in Renderer (happening only
with 2Gb off-heap overflow) so I keep both classes together in the same
patch as the fix in Renderer is very small.

The CrashTest seems faster now.

Laurent

2015-12-09 23:31 GMT+01:00 Jim Graham <james.graham at oracle.com>:

> Hi Laurent,
>
> That sounds good.  I'm all for fast tests!  ;)
>
> We might want to fix them in separate bugs, though.  If the new mods to
> the test case lead to failures, then we should integrate them after we fix
> the underlying problems, though, to prevent testing failures that might
> block an integration...
>
>                         ...jim
>
> On 12/9/15 2:25 PM, Laurent Bourg?s wrote:
>
>> Jim,
>>
>> Thanks for explaining me the different jtreg modes (newbie) !
>>
>> I tried disabling few long tests (using dashes) that are less critical
>> (no failure expected, just insane rendering work):
>>              test(0.1f, false, 0);
>>              test(0.1f, true, 7f);
>>
>> Doing so, I detected a new issue in the Renderer.dispose() when the
>> addLine() fails due to the AIOB (2GB off-heap overflow):
>> the range buckets_minY/maxY are not properly set, normally by
>> endRendering(), and the edgeBucket arrays are not properly zero-filled !
>>
>> I will work on this issue ASAP and propose a fix within the same bug.
>>
>> Maybe we should defer this fix as I agree it can be made faster ~ 12s
>> now vs 52s before on my laptop.
>>
>> Laurent
>>
>> 2015-12-09 22:31 GMT+01:00 Jim Graham <james.graham at oracle.com
>> <mailto:james.graham at oracle.com>>:
>>
>>
>>     Hi Laurent,
>>
>>     One clarification - there are levels of automation.
>>
>>     On 12/9/15 6:35 AM, Laurent Bourg?s wrote:
>>
>>         Agreed it is possible but then the bug JDK-8144446
>>         <https://bugs.openjdk.java.net/browse/JDK-8144446> becomes
>> invalid.
>>
>>
>>     Prior to this fix, jtreg wouldn't even see the test since it did not
>>     have any tags in it at all.  Adding tags of "some sort" makes it
>>     able to be run by the test mechanism, which I call "automated".
>>     Right now, nobody who runs jtreg will run this test no matter what
>>     command line arguments they use with the tool.
>>
>>     Once jtreg recognizes a test there are variations that let it decide
>>     when/if to run it.  It has 3 main modes (related to the /manual tag):
>>
>>     no options - all tests are run, both manual and automatic
>>     -a - ignore all /manual tests
>>     -m - run only /manual tests
>>
>>     -a primarily means "there is no human here to provide interaction",
>>     but a few non-manual tests take a long time.
>>
>>     On the other hand, I just did a test run of all tests (with -a) in
>>     sun/java2d and the total time was so long that the 30 seconds wasn't
>>     that noticeable.  On the other hand, there were a lot of tests run
>>     so the long time was less because a lot of tests take a long time
>>     than it was about the fact that a lot of conditions were tested in
>>     that time. For the record, the next longest test in that part of the
>>     repo takes 8 seconds, so this new test is almost 5 times longer than
>>     any existing java2d test.  Only the longest 4 tests took more than 5
>>     seconds.
>>
>>     I did find a test with "@ignore slow test" in another part of the
>>     repo and I ran it and it took 8 seconds as well, so somebody out
>>     there considers 8 seconds to be too long to run under ordinary
>>     circumstances.
>>
>>     I tend to want to push hard on making tests be faster and leaner.  I
>>     see so many bug fixes come in with automated tests that only have to
>>     run a single method and see if it returns the right answer and yet
>>     somehow the test needs to launch a Frame and wait for it to open and
>>     then do a screen readback - when a simple render to a BufferedImage
>>     would take 1/100th the time.
>>
>>     I'll withdraw my suggestion to make this one /manual, but it would
>>     be nice if it could do its work in just a few seconds instead...
>>
>>


-- 
-- 
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151210/6c0c0a9a/attachment.html>

From james.graham at oracle.com  Thu Dec 10 00:27:36 2015
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 9 Dec 2015 16:27:36 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <CAKjRUT6dCt7tsONipDatV=_3ANHO_7WsZcENN0JJQjDOYGAJ+g@mail.gmail.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
	<566219C4.303@oracle.com> <56621A48.7020406@oracle.com>
	<56663D94.6040304@oracle.com>
	<CAKjRUT7u+wm5x5eyG5o-3krMWtNwD3f_jc40zos4Gn0-CpTz9w@mail.gmail.com>
	<566763C2.7070800@oracle.com> <56682555.9020809@oracle.com>
	<CAKjRUT7qLSdYaBvN5Ci6HouP06iUJvefbGAYGikJF_Z4s4kNrg@mail.gmail.com>
	<56689D97.3070406@oracle.com>
	<CAKjRUT6wdiuSakCpLt8dtKX_upfYUY76Mrb+a7T-WdZF332KFg@mail.gmail.com>
	<5668ABDF.7030002@oracle.com>
	<CAKjRUT6dCt7tsONipDatV=_3ANHO_7WsZcENN0JJQjDOYGAJ+g@mail.gmail.com>
Message-ID: <5668C6F8.4020700@oracle.com>

Hi Laurent,

I did some more reading about jtreg and discovered that an @run is 
supposed to be assumed if none are present, but

The fix looks correct, but one thing I would tend to do for robustness 
is that in an error case, rather than duplicate the logic that was 
skipped (which can get out of date if we later change how the bounds*Y 
variables are calculated), I would just hardcode the bounds*Y variables 
to the worst case min/max so that we do a complete fill on the 
variables.  For error cases it is less interesting to optimize out every 
memory store and more interesting to make sure that we robustly restore 
the state.  Another option would be to move the bounds logic to a 
separate function that is called in both the error and the success cases?

For the test, you can have multiple test tags and include an @ignore so 
that the primary tests are run every time and the ones after the ignore 
are only run if someone runs with "-ignore:run".  That makes them 
runnable from the command line without having to edit the test:

@run main/othervm -mx512m CrashTest
@ignore tests that take a long time
@run main/othervm -mx512m CrashTest -slow

The first line would be run in all cases, the second line would only be 
run if they specify "-ignore:run" on the command line.

The only down side is that the tests after the @ignore are shown on the 
final statistics as "errors" which seems kind of melodramatic, but 
that's why the "-ignore:quiet" option exists.  There are quite a few 
tests in the java hierarchy with an @ignore tag, though, often talking 
about extreme memory requirements so this is nothing new.  This would be 
the first in the sun/java2d hierarchy, though...

		...jim

On 12/9/15 3:10 PM, Laurent Bourg?s wrote:
> Jim,
>
> My last chance for tonight !
>
> Here is another webrev that disables two long tests (dasher) in
> CrashTest but fixes a state cleanup bug in Renderer (doChecks=true):
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.2/
>
> Note: the modified CrashTest detected this bug in Renderer (happening
> only with 2Gb off-heap overflow) so I keep both classes together in the
> same patch as the fix in Renderer is very small.
>
> The CrashTest seems faster now.
>
> Laurent
>
> 2015-12-09 23:31 GMT+01:00 Jim Graham <james.graham at oracle.com
> <mailto:james.graham at oracle.com>>:
>
>     Hi Laurent,
>
>     That sounds good.  I'm all for fast tests!  ;)
>
>     We might want to fix them in separate bugs, though.  If the new mods
>     to the test case lead to failures, then we should integrate them
>     after we fix the underlying problems, though, to prevent testing
>     failures that might block an integration...
>
>                              ...jim
>
>     On 12/9/15 2:25 PM, Laurent Bourg?s wrote:
>
>         Jim,
>
>         Thanks for explaining me the different jtreg modes (newbie) !
>
>         I tried disabling few long tests (using dashes) that are less
>         critical
>         (no failure expected, just insane rendering work):
>                       test(0.1f, false, 0);
>                       test(0.1f, true, 7f);
>
>         Doing so, I detected a new issue in the Renderer.dispose() when the
>         addLine() fails due to the AIOB (2GB off-heap overflow):
>         the range buckets_minY/maxY are not properly set, normally by
>         endRendering(), and the edgeBucket arrays are not properly
>         zero-filled !
>
>         I will work on this issue ASAP and propose a fix within the same
>         bug.
>
>         Maybe we should defer this fix as I agree it can be made faster
>         ~ 12s
>         now vs 52s before on my laptop.
>
>         Laurent
>
>         2015-12-09 22:31 GMT+01:00 Jim Graham <james.graham at oracle.com
>         <mailto:james.graham at oracle.com>
>         <mailto:james.graham at oracle.com <mailto:james.graham at oracle.com>>>:
>
>
>              Hi Laurent,
>
>              One clarification - there are levels of automation.
>
>              On 12/9/15 6:35 AM, Laurent Bourg?s wrote:
>
>                  Agreed it is possible but then the bug JDK-8144446
>                  <https://bugs.openjdk.java.net/browse/JDK-8144446>
>         becomes invalid.
>
>
>              Prior to this fix, jtreg wouldn't even see the test since
>         it did not
>              have any tags in it at all.  Adding tags of "some sort"
>         makes it
>              able to be run by the test mechanism, which I call "automated".
>              Right now, nobody who runs jtreg will run this test no
>         matter what
>              command line arguments they use with the tool.
>
>              Once jtreg recognizes a test there are variations that let
>         it decide
>              when/if to run it.  It has 3 main modes (related to the
>         /manual tag):
>
>              no options - all tests are run, both manual and automatic
>              -a - ignore all /manual tests
>              -m - run only /manual tests
>
>              -a primarily means "there is no human here to provide
>         interaction",
>              but a few non-manual tests take a long time.
>
>              On the other hand, I just did a test run of all tests (with
>         -a) in
>              sun/java2d and the total time was so long that the 30
>         seconds wasn't
>              that noticeable.  On the other hand, there were a lot of
>         tests run
>              so the long time was less because a lot of tests take a
>         long time
>              than it was about the fact that a lot of conditions were
>         tested in
>              that time. For the record, the next longest test in that
>         part of the
>              repo takes 8 seconds, so this new test is almost 5 times
>         longer than
>              any existing java2d test.  Only the longest 4 tests took
>         more than 5
>              seconds.
>
>              I did find a test with "@ignore slow test" in another part
>         of the
>              repo and I ran it and it took 8 seconds as well, so
>         somebody out
>              there considers 8 seconds to be too long to run under ordinary
>              circumstances.
>
>              I tend to want to push hard on making tests be faster and
>         leaner.  I
>              see so many bug fixes come in with automated tests that
>         only have to
>              run a single method and see if it returns the right answer
>         and yet
>              somehow the test needs to launch a Frame and wait for it to
>         open and
>              then do a screen readback - when a simple render to a
>         BufferedImage
>              would take 1/100th the time.
>
>              I'll withdraw my suggestion to make this one /manual, but
>         it would
>              be nice if it could do its work in just a few seconds
>         instead...
>
>
>
>
> --
> --
> Laurent Bourg?s


From james.graham at oracle.com  Thu Dec 10 00:28:51 2015
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 9 Dec 2015 16:28:51 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <5668C6F8.4020700@oracle.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
	<566219C4.303@oracle.com> <56621A48.7020406@oracle.com>
	<56663D94.6040304@oracle.com>
	<CAKjRUT7u+wm5x5eyG5o-3krMWtNwD3f_jc40zos4Gn0-CpTz9w@mail.gmail.com>
	<566763C2.7070800@oracle.com> <56682555.9020809@oracle.com>
	<CAKjRUT7qLSdYaBvN5Ci6HouP06iUJvefbGAYGikJF_Z4s4kNrg@mail.gmail.com>
	<56689D97.3070406@oracle.com>
	<CAKjRUT6wdiuSakCpLt8dtKX_upfYUY76Mrb+a7T-WdZF332KFg@mail.gmail.com>
	<5668ABDF.7030002@oracle.com>
	<CAKjRUT6dCt7tsONipDatV=_3ANHO_7WsZcENN0JJQjDOYGAJ+g@mail.gmail.com>
	<5668C6F8.4020700@oracle.com>
Message-ID: <5668C743.1030607@oracle.com>

Ignore that first paragraph - a thought train that didn't go anywhere 
and I forgot to delete it...

			...jim

On 12/9/15 4:27 PM, Jim Graham wrote:
> Hi Laurent,
>
> I did some more reading about jtreg and discovered that an @run is
> supposed to be assumed if none are present, but
>
> The fix looks correct, but one thing I would tend to do for robustness
> is that in an error case, rather than duplicate the logic that was
> skipped (which can get out of date if we later change how the bounds*Y
> variables are calculated), I would just hardcode the bounds*Y variables
> to the worst case min/max so that we do a complete fill on the
> variables.  For error cases it is less interesting to optimize out every
> memory store and more interesting to make sure that we robustly restore
> the state.  Another option would be to move the bounds logic to a
> separate function that is called in both the error and the success cases?
>
> For the test, you can have multiple test tags and include an @ignore so
> that the primary tests are run every time and the ones after the ignore
> are only run if someone runs with "-ignore:run".  That makes them
> runnable from the command line without having to edit the test:
>
> @run main/othervm -mx512m CrashTest
> @ignore tests that take a long time
> @run main/othervm -mx512m CrashTest -slow
>
> The first line would be run in all cases, the second line would only be
> run if they specify "-ignore:run" on the command line.
>
> The only down side is that the tests after the @ignore are shown on the
> final statistics as "errors" which seems kind of melodramatic, but
> that's why the "-ignore:quiet" option exists.  There are quite a few
> tests in the java hierarchy with an @ignore tag, though, often talking
> about extreme memory requirements so this is nothing new.  This would be
> the first in the sun/java2d hierarchy, though...
>
>          ...jim
>
> On 12/9/15 3:10 PM, Laurent Bourg?s wrote:
>> Jim,
>>
>> My last chance for tonight !
>>
>> Here is another webrev that disables two long tests (dasher) in
>> CrashTest but fixes a state cleanup bug in Renderer (doChecks=true):
>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.2/
>>
>> Note: the modified CrashTest detected this bug in Renderer (happening
>> only with 2Gb off-heap overflow) so I keep both classes together in the
>> same patch as the fix in Renderer is very small.
>>
>> The CrashTest seems faster now.
>>
>> Laurent
>>
>> 2015-12-09 23:31 GMT+01:00 Jim Graham <james.graham at oracle.com
>> <mailto:james.graham at oracle.com>>:
>>
>>     Hi Laurent,
>>
>>     That sounds good.  I'm all for fast tests!  ;)
>>
>>     We might want to fix them in separate bugs, though.  If the new mods
>>     to the test case lead to failures, then we should integrate them
>>     after we fix the underlying problems, though, to prevent testing
>>     failures that might block an integration...
>>
>>                              ...jim
>>
>>     On 12/9/15 2:25 PM, Laurent Bourg?s wrote:
>>
>>         Jim,
>>
>>         Thanks for explaining me the different jtreg modes (newbie) !
>>
>>         I tried disabling few long tests (using dashes) that are less
>>         critical
>>         (no failure expected, just insane rendering work):
>>                       test(0.1f, false, 0);
>>                       test(0.1f, true, 7f);
>>
>>         Doing so, I detected a new issue in the Renderer.dispose()
>> when the
>>         addLine() fails due to the AIOB (2GB off-heap overflow):
>>         the range buckets_minY/maxY are not properly set, normally by
>>         endRendering(), and the edgeBucket arrays are not properly
>>         zero-filled !
>>
>>         I will work on this issue ASAP and propose a fix within the same
>>         bug.
>>
>>         Maybe we should defer this fix as I agree it can be made faster
>>         ~ 12s
>>         now vs 52s before on my laptop.
>>
>>         Laurent
>>
>>         2015-12-09 22:31 GMT+01:00 Jim Graham <james.graham at oracle.com
>>         <mailto:james.graham at oracle.com>
>>         <mailto:james.graham at oracle.com
>> <mailto:james.graham at oracle.com>>>:
>>
>>
>>              Hi Laurent,
>>
>>              One clarification - there are levels of automation.
>>
>>              On 12/9/15 6:35 AM, Laurent Bourg?s wrote:
>>
>>                  Agreed it is possible but then the bug JDK-8144446
>>                  <https://bugs.openjdk.java.net/browse/JDK-8144446>
>>         becomes invalid.
>>
>>
>>              Prior to this fix, jtreg wouldn't even see the test since
>>         it did not
>>              have any tags in it at all.  Adding tags of "some sort"
>>         makes it
>>              able to be run by the test mechanism, which I call
>> "automated".
>>              Right now, nobody who runs jtreg will run this test no
>>         matter what
>>              command line arguments they use with the tool.
>>
>>              Once jtreg recognizes a test there are variations that let
>>         it decide
>>              when/if to run it.  It has 3 main modes (related to the
>>         /manual tag):
>>
>>              no options - all tests are run, both manual and automatic
>>              -a - ignore all /manual tests
>>              -m - run only /manual tests
>>
>>              -a primarily means "there is no human here to provide
>>         interaction",
>>              but a few non-manual tests take a long time.
>>
>>              On the other hand, I just did a test run of all tests (with
>>         -a) in
>>              sun/java2d and the total time was so long that the 30
>>         seconds wasn't
>>              that noticeable.  On the other hand, there were a lot of
>>         tests run
>>              so the long time was less because a lot of tests take a
>>         long time
>>              than it was about the fact that a lot of conditions were
>>         tested in
>>              that time. For the record, the next longest test in that
>>         part of the
>>              repo takes 8 seconds, so this new test is almost 5 times
>>         longer than
>>              any existing java2d test.  Only the longest 4 tests took
>>         more than 5
>>              seconds.
>>
>>              I did find a test with "@ignore slow test" in another part
>>         of the
>>              repo and I ran it and it took 8 seconds as well, so
>>         somebody out
>>              there considers 8 seconds to be too long to run under
>> ordinary
>>              circumstances.
>>
>>              I tend to want to push hard on making tests be faster and
>>         leaner.  I
>>              see so many bug fixes come in with automated tests that
>>         only have to
>>              run a single method and see if it returns the right answer
>>         and yet
>>              somehow the test needs to launch a Frame and wait for it to
>>         open and
>>              then do a screen readback - when a simple render to a
>>         BufferedImage
>>              would take 1/100th the time.
>>
>>              I'll withdraw my suggestion to make this one /manual, but
>>         it would
>>              be nice if it could do its work in just a few seconds
>>         instead...
>>
>>
>>
>>
>> --
>> --
>> Laurent Bourg?s


From srl at icu-project.org  Thu Dec 10 00:44:13 2015
From: srl at icu-project.org (Steven R. Loomis)
Date: Wed, 9 Dec 2015 16:44:13 -0800
Subject: [OpenJDK 2D-Dev] Question regarding the integration of harfbuzz
	(JEP 258)
In-Reply-To: <56685F3D.9000607@oracle.com>
References: <56685EA9.8020704@oracle.com> <56685F3D.9000607@oracle.com>
Message-ID: <D6F95352-C873-4C54-AC90-08A4E3BBB305@icu-project.org>

Volker,
 0. I?d like to see what the crashing stack frame is when NOT on harfbuzz, because there should be no change.

 1. Phil addressed this one

 2. I will take a look on AIX. I?ll see if I can build Harfbuzz itself on AIX at first.

 3. Yes, I?ll work on putting some docs together for that test.  Actually, other tests such as the Font2DTest  would be a good test. Or, any text in a complex script such as Hindi.

 4. I?m not sure. A threaded stress test would be good.  Perhaps Harfbuzz-in-JDK could leverage the hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp you mentioned. 
 
 Behdad - file is here http://hg.openjdk.java.net/jdk9/client/hotspot/file/c8e212fb27d0/src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp  - any comments on this or other items? 

-s

> 
> -------- Original Message --------
> Subject:	Re: [OpenJDK 2D-Dev] Question regarding the integration of harfbuzz (JEP 258)
> Date:	Wed, 09 Dec 2015 09:02:33 -0800
> From:	Philip Race <philip.race at oracle.com> <mailto:philip.race at oracle.com>
> Organization:	Oracle Corporation
> To:	2d-dev at openjdk.java.net <mailto:2d-dev at openjdk.java.net>
> 
> Hi Volker,
> 
> Running with ICU should stop harfbuzz use completely so if
> you are still seeing a crash, perhaps it is due to something else entirely.
> Especially since a "simple AWT program" should not load layout anyway.
> There was a fair amount of new and changed code pushed recently ...
> 
> Yes, we need to run harfbuzz in multiple concurrent threads in the JDK.
> A single threaded lock on harfbuzz would throttle text operations.
> I suppose it is possible that we do not strictly need it as we currently 
> create a
> new harfbuzz "instance" each time we go to invoke layout but that
> is something that at least theoretically could change.
> 
> The approach to synchronization is all from up-stream harfbuzz.
> The harfbuzz mailing list might be the place to discuss that.
> I'd expect it does work on AIX as a principal driver here is that
> the IBM sponsored ICU project has deprecated its layout engine
> and IBM/ICU are moving to harfbuzz so I'd be somewhat astonished
> if they haven't yet tried it on AIX. Did you try just getting a copy
> of the full hotspot library and running its configure on AIX to see if
> harfbuzz can work out which options it wants there ? Obviously
> I did not try that since I don't have AIX. Steven Loomis of IBM
> who submitted the JEP should be able to help with a lot of this.
> 
> -phil.
> 
> On 12/8/15, 10:50 AM, Volker Simonis wrote:
> > Hi,
> >
> > the integration of harfbuzz broke our AIX build because there's no
> > implementation available for the hb_atomic macros in
> > hb-atomic-private.hh. I've fixed that locally but still get a crash
> > when running a simple AWT program (even with
> > -Dsun.font.layoutengine=icu).
> >
> > I'm curretnly debugging the problem, but I have some general questions:
> >
> > 1. Do we really need the multi-threaded features of harfbuzz in OpenJDK?
> >
> > 2. Why does hurbuzz require these synchronization macros? From a first
> > glance it doesn't seem to use multiple threads by itself. Does it have
> > some global data structures which it needs to protect if harfbuzz is
> > called from various threads?
> >
> > 3. Is there a way to test the hurfbuzz engine on a new platform? I saw
> > the new test TestLayoutVsICU.java but it is marked as "manual" and it
> > seems to require external fonts (at least some of which seem to be
> > freely available). Could you please provide at least a minimal
> > description on how this test can be run?
> >
> > 4. Is there a way to test that the implementation of the hb_atomic
> > macros in hb-atomic-private.hh is correct (i.e. a way to stress
> > harfbuzz from multiple threads)? I think this is important as I
> > couldn't find a good description of the requirements for the atomic
> > macros and on weak memory model architectures we should really get
> > this right. For example there's no description of which fences are
> > required around the various atomic operations. Getting this right
> > across all platforms in the HotSpot (see
> > hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp) is already hard
> > enough so I'm a little concerned that we are now introducing similar
> > primitives in the class library.
> >
> > Thank you and best regards,
> > Volker

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151209/53706429/attachment.html>

From philip.race at oracle.com  Thu Dec 10 06:47:08 2015
From: philip.race at oracle.com (Philip Race)
Date: Wed, 09 Dec 2015 22:47:08 -0800
Subject: [OpenJDK 2D-Dev] [9] RFR: Test
 closed/javax/print/attribute/Services_getDocFl.java fails with
 NullpointerException (8040139)
In-Reply-To: <565EC976.5060104@oracle.com>
References: <565EC976.5060104@oracle.com>
Message-ID: <56691FEC.7070606@oracle.com>

I had to hunt for this since you did not include the bug number in the 
subject line.
The fix is fine although you really should explain to people why this 
approach is
taken rather than ignoring the printer. i.e it is prohibitively 
expensive to use
"lpstat -p" when simply enumerating available printers.

And I think the closed test can be opened. I don't see any problem with 
it and
it was developed internally.

-phil.


On 12/2/15, 2:35 AM, prasanta sadhukhan wrote:
> Hi All,
>
> Please review a fix for jdk9
> Bug: https://bugs.openjdk.java.net/browse/JDK-8040139
> webrev: http://cr.openjdk.java.net/~jdv/prasanta/8040139/webrev.00/
>
> It seems if a IPP printer is not accessible, 
> PrintServiceLookup.lookupPrintServices will return the printer service 
> but PrintService.getSupportedDocFlavors() will return null
> since for the printer there is no way to answer the questions as to 
> what it supports and if after that someone tries to access 
> flavors.length it will cause NPE.
> However, as per spec
> /https://docs.oracle.com/javase/8/docs/api/index.html?javax/print/PrintService.html//
> //it clearly says, //
> /
>
> /Returns:/
>     /Array of supported doc flavors, should have at least one element./
>
>
> so returning null is a violation of spec.
> I have added a fix to return DocService.SERVICE_FORMATTED flavor for 
> such case.
>
> Could not add a reg testcase as it will need an inaccessible printer.
>
> Regards
> Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151209/39adfb00/attachment.html>

From prasanta.sadhukhan at oracle.com  Thu Dec 10 08:10:15 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Thu, 10 Dec 2015 13:40:15 +0530
Subject: [OpenJDK 2D-Dev] [9] RFR: Test
 closed/javax/print/attribute/Services_getDocFl.java fails with
 NullpointerException (8040139)
In-Reply-To: <56691FEC.7070606@oracle.com>
References: <565EC976.5060104@oracle.com> <56691FEC.7070606@oracle.com>
Message-ID: <56693367.1090807@oracle.com>

Thanks Phil for your approval.
I have opened up the closed test also. Here's the updated webrev:
http://cr.openjdk.java.net/~jdv/prasanta/8040139/webrev.01/

Sergey, would be able to +1 this?

Also, in addition to what Phil mentioned that it is expensive to 
enumerate for available printers in the network, we simply go for this 
fix to return an array with one entry in DocFlavor
if the printer(s) already registered/added are not available and when 
user goes to print through the dialog, they would see the printer is 
"stopped" or "unable to connect" instead of a NPE.

Regards
Prasanta
On 12/10/2015 12:17 PM, Philip Race wrote:
> I had to hunt for this since you did not include the bug number in the 
> subject line.
> The fix is fine although you really should explain to people why this 
> approach is
> taken rather than ignoring the printer. i.e it is prohibitively 
> expensive to use
> "lpstat -p" when simply enumerating available printers.
>
> And I think the closed test can be opened. I don't see any problem 
> with it and
> it was developed internally.
>
> -phil.
>
>
> On 12/2/15, 2:35 AM, prasanta sadhukhan wrote:
>> Hi All,
>>
>> Please review a fix for jdk9
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8040139
>> webrev: http://cr.openjdk.java.net/~jdv/prasanta/8040139/webrev.00/
>>
>> It seems if a IPP printer is not accessible, 
>> PrintServiceLookup.lookupPrintServices will return the printer 
>> service but PrintService.getSupportedDocFlavors() will return null
>> since for the printer there is no way to answer the questions as to 
>> what it supports and if after that someone tries to access 
>> flavors.length it will cause NPE.
>> However, as per spec
>> /https://docs.oracle.com/javase/8/docs/api/index.html?javax/print/PrintService.html//
>> //it clearly says, //
>> /
>>
>> /Returns:/
>>     /Array of supported doc flavors, should have at least one element./
>>
>>
>> so returning null is a violation of spec.
>> I have added a fix to return DocService.SERVICE_FORMATTED flavor for 
>> such case.
>>
>> Could not add a reg testcase as it will need an inaccessible printer.
>>
>> Regards
>> Prasanta

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151210/3c27a8b5/attachment.html>

From jayathirth.d.v at oracle.com  Thu Dec 10 11:39:59 2015
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Thu, 10 Dec 2015 03:39:59 -0800 (PST)
Subject: [OpenJDK 2D-Dev] [9] RFR: Test
 closed/javax/print/attribute/Services_getDocFl.java fails with
 NullpointerException (8040139)
In-Reply-To: <56693367.1090807@oracle.com>
References: <565EC976.5060104@oracle.com> <56691FEC.7070606@oracle.com>
	<56693367.1090807@oracle.com>
Message-ID: <8937fb21-a1d2-41c2-849f-f9adb8241118@default>

Fix looks good to me.

?

From: prasanta sadhukhan 
Sent: Thursday, December 10, 2015 1:40 PM
To: Philip Race; Sergey Bylokhov
Cc: 2d-dev at openjdk.java.net; Rajeev Chamyal
Subject: Re: [OpenJDK 2D-Dev] [9] RFR: Test closed/javax/print/attribute/Services_getDocFl.java fails with NullpointerException (8040139)

?

Thanks Phil for your approval.
I have opened up the closed test also. Here's the updated webrev:
http://cr.openjdk.java.net/~jdv/prasanta/8040139/webrev.01/

Sergey, would be able to +1 this?

Also, in addition to what Phil mentioned that it is expensive to enumerate for available printers in the network, we simply go for this fix to return an array with one entry in DocFlavor 
if the printer(s) already registered/added are not available and when user goes to print through the dialog, they would see the printer is "stopped" or "unable to connect" instead of a NPE.

Regards
Prasanta

On 12/10/2015 12:17 PM, Philip Race wrote:

I had to hunt for this since you did not include the bug number in the subject line.
The fix is fine although you really should explain to people why this approach is
taken rather than ignoring the printer. i.e it is prohibitively expensive to use
"lpstat -p" when simply enumerating available printers.

And I think the closed test can be opened. I don't see any problem with it and
it was developed internally.

-phil.


On 12/2/15, 2:35 AM, prasanta sadhukhan wrote: 

Hi All,

Please review a fix for jdk9 
Bug: https://bugs.openjdk.java.net/browse/JDK-8040139
webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/prasanta/8040139/webrev.00/"http://cr.openjdk.java.net/~jdv/prasanta/8040139/webrev.00/

It seems if a IPP printer is not accessible, PrintServiceLookup.lookupPrintServices will return the printer service but PrintService.getSupportedDocFlavors() will return null
since for the printer there is no way to answer the questions as to what it supports and if after that someone tries to access flavors.length it will cause NPE.
However, as per spec
https://docs.oracle.com/javase/8/docs/api/index.html?javax/print/PrintService.html
it clearly says, ??? 

Returns:

Array of supported doc flavors, should have at least one element.


so returning null is a violation of spec. 
I have added a fix to return DocService.SERVICE_FORMATTED flavor for such case.

Could not add a reg testcase as it will need an inaccessible printer.

Regards
Prasanta

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151210/b076c3de/attachment.html>

From Sergey.Bylokhov at oracle.com  Thu Dec 10 12:44:18 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 10 Dec 2015 15:44:18 +0300
Subject: [OpenJDK 2D-Dev] RFR 6488522: PNG writer should permit setting
 compression level and iDAT chunk maximum size
In-Reply-To: <CAKjRUT5fu6fj1ugZ3Yf+C_RzNxRxqVyTb5my2GW5v=jr+n1+dA@mail.gmail.com>
References: <CAKjRUT4T7L8cK=SP0QM1LK-azLNexA0RNoq2FEFSdbSFetYr6g@mail.gmail.com>
	<56682A5E.6080904@oracle.com>
	<CAKjRUT5fu6fj1ugZ3Yf+C_RzNxRxqVyTb5my2GW5v=jr+n1+dA@mail.gmail.com>
Message-ID: <566973A2.3000300@oracle.com>

On 09/12/15 17:17, Laurent Bourg?s wrote:
> Hi Sergey,
>
> Thanks for your comments, did you review the PNGImageWriter changes too ?

A few notes:
  - Should PNGImageWriteParam.unsetCompression resets the 
compressionType to compressionTypes[0]?
  - Is it necessary to copy the checks in PNGImageWriteParam from the 
parent? We can just call super() and expect that the parent class 
validate current state.

> Yes, I could check that every png file is not zero-length or that better
> compression gives smaller file size !

It would be good, because right now it check not all changes in the fix.

> However, my changes rely on the public Deflater API that supports
> compression levels between 0 to 9.
>
> I suppose that this Deflater class is already covered by its own tests
> so I would prefer leaving the test as it is (no verification):  if the
> Deflater raises any RuntimeException, then the PNGWriterCompressionTest
> will fail.

But this test is passed even for such fix:

--- 
a/src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java 
Thu Dec 10 14:21:44 2015 +0300
+++ 
b/src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java 
Thu Dec 10 15:15:41 2015 +0300
@@ -280,6 +280,7 @@
          super();
          this.canWriteProgressive = true;
          this.locale = locale;
+        this.canWriteCompressed = true;
      }
  }

> Why not but it is a different scope ?
>
> I wrote the test focused on testing my patch to validate all my changes
> and fix ASAP that very old bug (created in 2006) !

I understood, but to change the test and cover of existed/future plugins 
should not require a big effort. It does not mean that you need to fix 
some bugs(if any then create a new CR) in other plugins.
See for example this bug JDK-8144245 which was found in a new plugin 
just because the test cover all of them. But this is up2you.


-- 
Best regards, Sergey.


From volker.simonis at gmail.com  Thu Dec 10 13:13:43 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 10 Dec 2015 14:13:43 +0100
Subject: [OpenJDK 2D-Dev] RFR(S): 8145077: AIX: fix harfbuzz support
Message-ID: <CA+3eh11B-RN03Hxa7NnicVVteXeh_=1byg9cF7Y8amemjg+9zw@mail.gmail.com>

Hi,

could somebody please review this AIX-only fix which adds the harfbuzz
atomic primitives for AIX:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8145077/
https://bugs.openjdk.java.net/browse/JDK-8145077

I plan to also submit this patch upstream to the harfbuzz project to
minimize the diffs between the upstream and the OpenJDK version.

Notice that although this is a client patch I plan to push this
directly to jdk9-dev because it fixes a build failure and I don't want
to wait for the next round-trip trough jdk9-client.

Thank you and best regards,
Volker


From volker.simonis at gmail.com  Thu Dec 10 13:27:34 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 10 Dec 2015 14:27:34 +0100
Subject: [OpenJDK 2D-Dev] Question regarding the integration of harfbuzz
 (JEP 258)
In-Reply-To: <D6F95352-C873-4C54-AC90-08A4E3BBB305@icu-project.org>
References: <56685EA9.8020704@oracle.com> <56685F3D.9000607@oracle.com>
	<D6F95352-C873-4C54-AC90-08A4E3BBB305@icu-project.org>
Message-ID: <CA+3eh12V-G2L4uc5G=Yj75tG_KYUDDiud6zpYxwSHJ0VjC1QPA@mail.gmail.com>

Hi Steven,

thanks for your response.

On Thu, Dec 10, 2015 at 1:44 AM, Steven R. Loomis <srl at icu-project.org>
wrote:

> Volker,
>  0. I?d like to see what the crashing stack frame is when NOT on harfbuzz,
> because there should be no change.
>
>
This was another problem. Please see my previous mail in this thread where
I've described the cause in more detail.


>  1. Phil addressed this one
>
>  2. I will take a look on AIX. I?ll see if I can build Harfbuzz itself on
> AIX at first.
>
>
I've fixed it now and just send around a request for review:
http://mail.openjdk.java.net/pipermail/2d-dev/2015-December/006065.html

The mail contains a link to the bug and the patch which fixes it.

I also want to contribute this to harfbuzz. Is it OK to send a pull request
to https://github.com/behdad/harfbuzz ?

 3. Yes, I?ll work on putting some docs together for that test.  Actually,
> other tests such as the Font2DTest  would be a good test. Or, any text in a
> complex script such as Hindi.
>
>
That would be great. For now, the Font2DTest runs without a problem with
harfbuzz on AIX (and linux/ppc64).


>  4. I?m not sure. A threaded stress test would be good.  Perhaps
> Harfbuzz-in-JDK could leverage the
> hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp you mentioned.
>
>  Behdad - file is here
> http://hg.openjdk.java.net/jdk9/client/hotspot/file/c8e212fb27d0/src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp
>  - any comments on this or other items?
>
>
That sounds like a good idea but unfortunately the hotspot primitives are
in a different repository (source-code wise) and in a different library
(i.e. libjvm.so) which doesn't export them. So the best we can do for now
would be to copy the missing parts over to the jdk repository (and that's
actually what I've done now for the AIX version of the primitives).

Regards,
Volker


> -s
>
>
> -------- Original Message -------- Subject: Re: [OpenJDK 2D-Dev] Question
> regarding the integration of harfbuzz (JEP 258) Date: Wed, 09 Dec 2015
> 09:02:33 -0800 From: Philip Race <philip.race at oracle.com>
> <philip.race at oracle.com> Organization: Oracle Corporation To:
> 2d-dev at openjdk.java.net
>
>
> Hi Volker,
>
> Running with ICU should stop harfbuzz use completely so if
> you are still seeing a crash, perhaps it is due to something else entirely.
> Especially since a "simple AWT program" should not load layout anyway.
> There was a fair amount of new and changed code pushed recently ...
>
> Yes, we need to run harfbuzz in multiple concurrent threads in the JDK.
> A single threaded lock on harfbuzz would throttle text operations.
> I suppose it is possible that we do not strictly need it as we currently
> create a
> new harfbuzz "instance" each time we go to invoke layout but that
> is something that at least theoretically could change.
>
> The approach to synchronization is all from up-stream harfbuzz.
> The harfbuzz mailing list might be the place to discuss that.
> I'd expect it does work on AIX as a principal driver here is that
> the IBM sponsored ICU project has deprecated its layout engine
> and IBM/ICU are moving to harfbuzz so I'd be somewhat astonished
> if they haven't yet tried it on AIX. Did you try just getting a copy
> of the full hotspot library and running its configure on AIX to see if
> harfbuzz can work out which options it wants there ? Obviously
> I did not try that since I don't have AIX. Steven Loomis of IBM
> who submitted the JEP should be able to help with a lot of this.
>
> -phil.
>
> On 12/8/15, 10:50 AM, Volker Simonis wrote:
> > Hi,
> >
> > the integration of harfbuzz broke our AIX build because there's no
> > implementation available for the hb_atomic macros in
> > hb-atomic-private.hh. I've fixed that locally but still get a crash
> > when running a simple AWT program (even with
> > -Dsun.font.layoutengine=icu).
> >
> > I'm curretnly debugging the problem, but I have some general questions:
> >
> > 1. Do we really need the multi-threaded features of harfbuzz in OpenJDK?
> >
> > 2. Why does hurbuzz require these synchronization macros? From a first
> > glance it doesn't seem to use multiple threads by itself. Does it have
> > some global data structures which it needs to protect if harfbuzz is
> > called from various threads?
> >
> > 3. Is there a way to test the hurfbuzz engine on a new platform? I saw
> > the new test TestLayoutVsICU.java but it is marked as "manual" and it
> > seems to require external fonts (at least some of which seem to be
> > freely available). Could you please provide at least a minimal
> > description on how this test can be run?
> >
> > 4. Is there a way to test that the implementation of the hb_atomic
> > macros in hb-atomic-private.hh is correct (i.e. a way to stress
> > harfbuzz from multiple threads)? I think this is important as I
> > couldn't find a good description of the requirements for the atomic
> > macros and on weak memory model architectures we should really get
> > this right. For example there's no description of which fences are
> > required around the various atomic operations. Getting this right
> > across all platforms in the HotSpot (see
> > hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp) is already hard
> > enough so I'm a little concerned that we are now introducing similar
> > primitives in the class library.
> >
> > Thank you and best regards,
> > Volker
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151210/176dbd0f/attachment.html>

From volker.simonis at gmail.com  Thu Dec 10 16:12:38 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 10 Dec 2015 17:12:38 +0100
Subject: [OpenJDK 2D-Dev] Question regarding the integration of harfbuzz
 (JEP 258)
In-Reply-To: <CAOY=jUTkf3Y4jjqsSbx8ErgiBNhRQvjPSVETbOVqUa9ABFshAg@mail.gmail.com>
References: <56685EA9.8020704@oracle.com> <56685F3D.9000607@oracle.com>
	<D6F95352-C873-4C54-AC90-08A4E3BBB305@icu-project.org>
	<CA+3eh12V-G2L4uc5G=Yj75tG_KYUDDiud6zpYxwSHJ0VjC1QPA@mail.gmail.com>
	<CAOY=jUQKRUSdukaRHQ60r_+hVw6=z=nr1sRjB+OwkXx49nMO2A@mail.gmail.com>
	<CAOY=jUTkf3Y4jjqsSbx8ErgiBNhRQvjPSVETbOVqUa9ABFshAg@mail.gmail.com>
Message-ID: <CA+3eh109hpcmg816+9K0gffzjxpa3NRazW=ZSJFko7a3v0Tu+A@mail.gmail.com>

Behdad,

you're really great!!!

I've forked HarfBuzz today because I wanted to submit a pull request with
the change. Unfortunately I was not able to build on AIX until now (plenty
of nasty problems will all kind of missing or too old tools :(

And now I see that you've already pushed the change! Thanks a lot. I'd only
like to suggest the following minor enhancement to my initial change. It
restricts the change to the case where HarfBuzz will be compiled with IBM's
xlC compiler because it uses xlC compiler intrinsics. I know there are
people out there who package open source software for AIX but they usually
compile the whole toolchain with GCC. This minor addition will protect them
from running into compile errors if they should ever try to compile
HarfBuzz with GCC on AIX.

It would be great if you could add that as well to the upstream version.

I will then update my OpenJDK patch to contain exactly your "shuffeled"
upstream version so we don't get any problems when merging from upstream in
the future.

Thanks a lot once again,
Volker


diff -r fd95f33023e9
src/java.desktop/share/native/libfontmanager/harfbuzz/hb-atomic-private.hh
---
a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-atomic-private.hh
Thu Dec 10 12:13:22 2015 +0100
+++
b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-atomic-private.hh
Thu Dec 10 16:55:58 2015 +0100
@@ -119,7 +119,7 @@
 #define hb_atomic_ptr_impl_cmpexch(P,O,N)       ( ({__machine_rw_barrier
();}), atomic_cas_ptr ((void **) (P), (void *) (O), (void *) (N)) == (void
*) (O) ? true : false)


-#elif !defined(HB_NO_MT) && defined(_AIX)
+#elif !defined(HB_NO_MT) && defined(_AIX) && defined(__IBMCPP__)

 #include <builtins.h>



On Thu, Dec 10, 2015 at 3:55 PM, Behdad Esfahbod <behdad at google.com> wrote:

> Slightly shuffled patch was committed upstream:
>
> https://github.com/behdad/harfbuzz/commit/70b33edae7c8b9c031b83c95f00cb383789f1041
>
> Thanks,
> behdad
>
>
> On Thu, Dec 10, 2015 at 2:36 PM, Behdad Esfahbod <behdad at google.com>
> wrote:
>
>> Hi Volker, Steven,
>>
>> I'd happily take AIX atomic primitive patch for HarfBuzz.  Yes, github
>> Pull-Requests are fine.  As you correctly identified, HarfBuzz uses atomic
>> ops and mutexes to synchronize access to global data as well as
>> reference-counting from multiple threads, even though it doesn't uses
>> threads itself.
>>
>> Does AIX use pthread for threading?  I can definitely add a threading
>> stress-test to HarfBuzz.  I definitely should.  Filed here:
>>
>>   https://github.com/behdad/harfbuzz/issues/195
>>
>> Thanks,
>> behdad
>>
>> On Thu, Dec 10, 2015 at 2:27 PM, Volker Simonis <volker.simonis at gmail.com
>> > wrote:
>>
>>> Hi Steven,
>>>
>>> thanks for your response.
>>>
>>> On Thu, Dec 10, 2015 at 1:44 AM, Steven R. Loomis <srl at icu-project.org>
>>> wrote:
>>>
>>>> Volker,
>>>>  0. I?d like to see what the crashing stack frame is when NOT on
>>>> harfbuzz, because there should be no change.
>>>>
>>>>
>>> This was another problem. Please see my previous mail in this thread
>>> where I've described the cause in more detail.
>>>
>>>
>>>>  1. Phil addressed this one
>>>>
>>>>  2. I will take a look on AIX. I?ll see if I can build Harfbuzz itself
>>>> on AIX at first.
>>>>
>>>>
>>> I've fixed it now and just send around a request for review:
>>> http://mail.openjdk.java.net/pipermail/2d-dev/2015-December/006065.html
>>>
>>> The mail contains a link to the bug and the patch which fixes it.
>>>
>>> I also want to contribute this to harfbuzz. Is it OK to send a pull
>>> request to https://github.com/behdad/harfbuzz ?
>>>
>>>  3. Yes, I?ll work on putting some docs together for that test.
>>>> Actually, other tests such as the Font2DTest  would be a good test. Or, any
>>>> text in a complex script such as Hindi.
>>>>
>>>>
>>> That would be great. For now, the Font2DTest runs without a problem with
>>> harfbuzz on AIX (and linux/ppc64).
>>>
>>>
>>>>  4. I?m not sure. A threaded stress test would be good.  Perhaps
>>>> Harfbuzz-in-JDK could leverage the
>>>> hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp you mentioned.
>>>>
>>>>  Behdad - file is here
>>>> http://hg.openjdk.java.net/jdk9/client/hotspot/file/c8e212fb27d0/src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp
>>>>  - any comments on this or other items?
>>>>
>>>>
>>> That sounds like a good idea but unfortunately the hotspot primitives
>>> are in a different repository (source-code wise) and in a different library
>>> (i.e. libjvm.so) which doesn't export them. So the best we can do for now
>>> would be to copy the missing parts over to the jdk repository (and that's
>>> actually what I've done now for the AIX version of the primitives).
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>>> -s
>>>>
>>>>
>>>> -------- Original Message -------- Subject: Re: [OpenJDK 2D-Dev]
>>>> Question regarding the integration of harfbuzz (JEP 258) Date: Wed, 09
>>>> Dec 2015 09:02:33 -0800 From: Philip Race <philip.race at oracle.com>
>>>> <philip.race at oracle.com> Organization: Oracle Corporation To:
>>>> 2d-dev at openjdk.java.net
>>>>
>>>>
>>>> Hi Volker,
>>>>
>>>> Running with ICU should stop harfbuzz use completely so if
>>>> you are still seeing a crash, perhaps it is due to something else entirely.
>>>> Especially since a "simple AWT program" should not load layout anyway.
>>>> There was a fair amount of new and changed code pushed recently ...
>>>>
>>>> Yes, we need to run harfbuzz in multiple concurrent threads in the JDK.
>>>> A single threaded lock on harfbuzz would throttle text operations.
>>>> I suppose it is possible that we do not strictly need it as we currently
>>>> create a
>>>> new harfbuzz "instance" each time we go to invoke layout but that
>>>> is something that at least theoretically could change.
>>>>
>>>> The approach to synchronization is all from up-stream harfbuzz.
>>>> The harfbuzz mailing list might be the place to discuss that.
>>>> I'd expect it does work on AIX as a principal driver here is that
>>>> the IBM sponsored ICU project has deprecated its layout engine
>>>> and IBM/ICU are moving to harfbuzz so I'd be somewhat astonished
>>>> if they haven't yet tried it on AIX. Did you try just getting a copy
>>>> of the full hotspot library and running its configure on AIX to see if
>>>> harfbuzz can work out which options it wants there ? Obviously
>>>> I did not try that since I don't have AIX. Steven Loomis of IBM
>>>> who submitted the JEP should be able to help with a lot of this.
>>>>
>>>> -phil.
>>>>
>>>> On 12/8/15, 10:50 AM, Volker Simonis wrote:
>>>> > Hi,
>>>> >
>>>> > the integration of harfbuzz broke our AIX build because there's no
>>>> > implementation available for the hb_atomic macros in
>>>> > hb-atomic-private.hh. I've fixed that locally but still get a crash
>>>> > when running a simple AWT program (even with
>>>> > -Dsun.font.layoutengine=icu).
>>>> >
>>>> > I'm curretnly debugging the problem, but I have some general questions:
>>>> >
>>>> > 1. Do we really need the multi-threaded features of harfbuzz in OpenJDK?
>>>> >
>>>> > 2. Why does hurbuzz require these synchronization macros? From a first
>>>> > glance it doesn't seem to use multiple threads by itself. Does it have
>>>> > some global data structures which it needs to protect if harfbuzz is
>>>> > called from various threads?
>>>> >
>>>> > 3. Is there a way to test the hurfbuzz engine on a new platform? I saw
>>>> > the new test TestLayoutVsICU.java but it is marked as "manual" and it
>>>> > seems to require external fonts (at least some of which seem to be
>>>> > freely available). Could you please provide at least a minimal
>>>> > description on how this test can be run?
>>>> >
>>>> > 4. Is there a way to test that the implementation of the hb_atomic
>>>> > macros in hb-atomic-private.hh is correct (i.e. a way to stress
>>>> > harfbuzz from multiple threads)? I think this is important as I
>>>> > couldn't find a good description of the requirements for the atomic
>>>> > macros and on weak memory model architectures we should really get
>>>> > this right. For example there's no description of which fences are
>>>> > required around the various atomic operations. Getting this right
>>>> > across all platforms in the HotSpot (see
>>>> > hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp) is already hard
>>>> > enough so I'm a little concerned that we are now introducing similar
>>>> > primitives in the class library.
>>>> >
>>>> > Thank you and best regards,
>>>> > Volker
>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151210/78f2f38e/attachment.html>

From behdad at google.com  Thu Dec 10 13:36:29 2015
From: behdad at google.com (Behdad Esfahbod)
Date: Thu, 10 Dec 2015 14:36:29 +0100
Subject: [OpenJDK 2D-Dev] Question regarding the integration of harfbuzz
 (JEP 258)
In-Reply-To: <CA+3eh12V-G2L4uc5G=Yj75tG_KYUDDiud6zpYxwSHJ0VjC1QPA@mail.gmail.com>
References: <56685EA9.8020704@oracle.com> <56685F3D.9000607@oracle.com>
	<D6F95352-C873-4C54-AC90-08A4E3BBB305@icu-project.org>
	<CA+3eh12V-G2L4uc5G=Yj75tG_KYUDDiud6zpYxwSHJ0VjC1QPA@mail.gmail.com>
Message-ID: <CAOY=jUQKRUSdukaRHQ60r_+hVw6=z=nr1sRjB+OwkXx49nMO2A@mail.gmail.com>

Hi Volker, Steven,

I'd happily take AIX atomic primitive patch for HarfBuzz.  Yes, github
Pull-Requests are fine.  As you correctly identified, HarfBuzz uses atomic
ops and mutexes to synchronize access to global data as well as
reference-counting from multiple threads, even though it doesn't uses
threads itself.

Does AIX use pthread for threading?  I can definitely add a threading
stress-test to HarfBuzz.  I definitely should.  Filed here:

  https://github.com/behdad/harfbuzz/issues/195

Thanks,
behdad

On Thu, Dec 10, 2015 at 2:27 PM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi Steven,
>
> thanks for your response.
>
> On Thu, Dec 10, 2015 at 1:44 AM, Steven R. Loomis <srl at icu-project.org>
> wrote:
>
>> Volker,
>>  0. I?d like to see what the crashing stack frame is when NOT on
>> harfbuzz, because there should be no change.
>>
>>
> This was another problem. Please see my previous mail in this thread where
> I've described the cause in more detail.
>
>
>>  1. Phil addressed this one
>>
>>  2. I will take a look on AIX. I?ll see if I can build Harfbuzz itself on
>> AIX at first.
>>
>>
> I've fixed it now and just send around a request for review:
> http://mail.openjdk.java.net/pipermail/2d-dev/2015-December/006065.html
>
> The mail contains a link to the bug and the patch which fixes it.
>
> I also want to contribute this to harfbuzz. Is it OK to send a pull
> request to https://github.com/behdad/harfbuzz ?
>
>  3. Yes, I?ll work on putting some docs together for that test.  Actually,
>> other tests such as the Font2DTest  would be a good test. Or, any text in a
>> complex script such as Hindi.
>>
>>
> That would be great. For now, the Font2DTest runs without a problem with
> harfbuzz on AIX (and linux/ppc64).
>
>
>>  4. I?m not sure. A threaded stress test would be good.  Perhaps
>> Harfbuzz-in-JDK could leverage the
>> hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp you mentioned.
>>
>>  Behdad - file is here
>> http://hg.openjdk.java.net/jdk9/client/hotspot/file/c8e212fb27d0/src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp
>>  - any comments on this or other items?
>>
>>
> That sounds like a good idea but unfortunately the hotspot primitives are
> in a different repository (source-code wise) and in a different library
> (i.e. libjvm.so) which doesn't export them. So the best we can do for now
> would be to copy the missing parts over to the jdk repository (and that's
> actually what I've done now for the AIX version of the primitives).
>
> Regards,
> Volker
>
>
>> -s
>>
>>
>> -------- Original Message -------- Subject: Re: [OpenJDK 2D-Dev]
>> Question regarding the integration of harfbuzz (JEP 258) Date: Wed, 09
>> Dec 2015 09:02:33 -0800 From: Philip Race <philip.race at oracle.com>
>> <philip.race at oracle.com> Organization: Oracle Corporation To:
>> 2d-dev at openjdk.java.net
>>
>>
>> Hi Volker,
>>
>> Running with ICU should stop harfbuzz use completely so if
>> you are still seeing a crash, perhaps it is due to something else entirely.
>> Especially since a "simple AWT program" should not load layout anyway.
>> There was a fair amount of new and changed code pushed recently ...
>>
>> Yes, we need to run harfbuzz in multiple concurrent threads in the JDK.
>> A single threaded lock on harfbuzz would throttle text operations.
>> I suppose it is possible that we do not strictly need it as we currently
>> create a
>> new harfbuzz "instance" each time we go to invoke layout but that
>> is something that at least theoretically could change.
>>
>> The approach to synchronization is all from up-stream harfbuzz.
>> The harfbuzz mailing list might be the place to discuss that.
>> I'd expect it does work on AIX as a principal driver here is that
>> the IBM sponsored ICU project has deprecated its layout engine
>> and IBM/ICU are moving to harfbuzz so I'd be somewhat astonished
>> if they haven't yet tried it on AIX. Did you try just getting a copy
>> of the full hotspot library and running its configure on AIX to see if
>> harfbuzz can work out which options it wants there ? Obviously
>> I did not try that since I don't have AIX. Steven Loomis of IBM
>> who submitted the JEP should be able to help with a lot of this.
>>
>> -phil.
>>
>> On 12/8/15, 10:50 AM, Volker Simonis wrote:
>> > Hi,
>> >
>> > the integration of harfbuzz broke our AIX build because there's no
>> > implementation available for the hb_atomic macros in
>> > hb-atomic-private.hh. I've fixed that locally but still get a crash
>> > when running a simple AWT program (even with
>> > -Dsun.font.layoutengine=icu).
>> >
>> > I'm curretnly debugging the problem, but I have some general questions:
>> >
>> > 1. Do we really need the multi-threaded features of harfbuzz in OpenJDK?
>> >
>> > 2. Why does hurbuzz require these synchronization macros? From a first
>> > glance it doesn't seem to use multiple threads by itself. Does it have
>> > some global data structures which it needs to protect if harfbuzz is
>> > called from various threads?
>> >
>> > 3. Is there a way to test the hurfbuzz engine on a new platform? I saw
>> > the new test TestLayoutVsICU.java but it is marked as "manual" and it
>> > seems to require external fonts (at least some of which seem to be
>> > freely available). Could you please provide at least a minimal
>> > description on how this test can be run?
>> >
>> > 4. Is there a way to test that the implementation of the hb_atomic
>> > macros in hb-atomic-private.hh is correct (i.e. a way to stress
>> > harfbuzz from multiple threads)? I think this is important as I
>> > couldn't find a good description of the requirements for the atomic
>> > macros and on weak memory model architectures we should really get
>> > this right. For example there's no description of which fences are
>> > required around the various atomic operations. Getting this right
>> > across all platforms in the HotSpot (see
>> > hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp) is already hard
>> > enough so I'm a little concerned that we are now introducing similar
>> > primitives in the class library.
>> >
>> > Thank you and best regards,
>> > Volker
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151210/a060ac88/attachment.html>

From behdad at google.com  Thu Dec 10 14:55:48 2015
From: behdad at google.com (Behdad Esfahbod)
Date: Thu, 10 Dec 2015 15:55:48 +0100
Subject: [OpenJDK 2D-Dev] Question regarding the integration of harfbuzz
 (JEP 258)
In-Reply-To: <CAOY=jUQKRUSdukaRHQ60r_+hVw6=z=nr1sRjB+OwkXx49nMO2A@mail.gmail.com>
References: <56685EA9.8020704@oracle.com> <56685F3D.9000607@oracle.com>
	<D6F95352-C873-4C54-AC90-08A4E3BBB305@icu-project.org>
	<CA+3eh12V-G2L4uc5G=Yj75tG_KYUDDiud6zpYxwSHJ0VjC1QPA@mail.gmail.com>
	<CAOY=jUQKRUSdukaRHQ60r_+hVw6=z=nr1sRjB+OwkXx49nMO2A@mail.gmail.com>
Message-ID: <CAOY=jUTkf3Y4jjqsSbx8ErgiBNhRQvjPSVETbOVqUa9ABFshAg@mail.gmail.com>

Slightly shuffled patch was committed upstream:
https://github.com/behdad/harfbuzz/commit/70b33edae7c8b9c031b83c95f00cb383789f1041

Thanks,
behdad


On Thu, Dec 10, 2015 at 2:36 PM, Behdad Esfahbod <behdad at google.com> wrote:

> Hi Volker, Steven,
>
> I'd happily take AIX atomic primitive patch for HarfBuzz.  Yes, github
> Pull-Requests are fine.  As you correctly identified, HarfBuzz uses atomic
> ops and mutexes to synchronize access to global data as well as
> reference-counting from multiple threads, even though it doesn't uses
> threads itself.
>
> Does AIX use pthread for threading?  I can definitely add a threading
> stress-test to HarfBuzz.  I definitely should.  Filed here:
>
>   https://github.com/behdad/harfbuzz/issues/195
>
> Thanks,
> behdad
>
> On Thu, Dec 10, 2015 at 2:27 PM, Volker Simonis <volker.simonis at gmail.com>
> wrote:
>
>> Hi Steven,
>>
>> thanks for your response.
>>
>> On Thu, Dec 10, 2015 at 1:44 AM, Steven R. Loomis <srl at icu-project.org>
>> wrote:
>>
>>> Volker,
>>>  0. I?d like to see what the crashing stack frame is when NOT on
>>> harfbuzz, because there should be no change.
>>>
>>>
>> This was another problem. Please see my previous mail in this thread
>> where I've described the cause in more detail.
>>
>>
>>>  1. Phil addressed this one
>>>
>>>  2. I will take a look on AIX. I?ll see if I can build Harfbuzz itself
>>> on AIX at first.
>>>
>>>
>> I've fixed it now and just send around a request for review:
>> http://mail.openjdk.java.net/pipermail/2d-dev/2015-December/006065.html
>>
>> The mail contains a link to the bug and the patch which fixes it.
>>
>> I also want to contribute this to harfbuzz. Is it OK to send a pull
>> request to https://github.com/behdad/harfbuzz ?
>>
>>  3. Yes, I?ll work on putting some docs together for that test.
>>> Actually, other tests such as the Font2DTest  would be a good test. Or, any
>>> text in a complex script such as Hindi.
>>>
>>>
>> That would be great. For now, the Font2DTest runs without a problem with
>> harfbuzz on AIX (and linux/ppc64).
>>
>>
>>>  4. I?m not sure. A threaded stress test would be good.  Perhaps
>>> Harfbuzz-in-JDK could leverage the
>>> hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp you mentioned.
>>>
>>>  Behdad - file is here
>>> http://hg.openjdk.java.net/jdk9/client/hotspot/file/c8e212fb27d0/src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp
>>>  - any comments on this or other items?
>>>
>>>
>> That sounds like a good idea but unfortunately the hotspot primitives are
>> in a different repository (source-code wise) and in a different library
>> (i.e. libjvm.so) which doesn't export them. So the best we can do for now
>> would be to copy the missing parts over to the jdk repository (and that's
>> actually what I've done now for the AIX version of the primitives).
>>
>> Regards,
>> Volker
>>
>>
>>> -s
>>>
>>>
>>> -------- Original Message -------- Subject: Re: [OpenJDK 2D-Dev]
>>> Question regarding the integration of harfbuzz (JEP 258) Date: Wed, 09
>>> Dec 2015 09:02:33 -0800 From: Philip Race <philip.race at oracle.com>
>>> <philip.race at oracle.com> Organization: Oracle Corporation To:
>>> 2d-dev at openjdk.java.net
>>>
>>>
>>> Hi Volker,
>>>
>>> Running with ICU should stop harfbuzz use completely so if
>>> you are still seeing a crash, perhaps it is due to something else entirely.
>>> Especially since a "simple AWT program" should not load layout anyway.
>>> There was a fair amount of new and changed code pushed recently ...
>>>
>>> Yes, we need to run harfbuzz in multiple concurrent threads in the JDK.
>>> A single threaded lock on harfbuzz would throttle text operations.
>>> I suppose it is possible that we do not strictly need it as we currently
>>> create a
>>> new harfbuzz "instance" each time we go to invoke layout but that
>>> is something that at least theoretically could change.
>>>
>>> The approach to synchronization is all from up-stream harfbuzz.
>>> The harfbuzz mailing list might be the place to discuss that.
>>> I'd expect it does work on AIX as a principal driver here is that
>>> the IBM sponsored ICU project has deprecated its layout engine
>>> and IBM/ICU are moving to harfbuzz so I'd be somewhat astonished
>>> if they haven't yet tried it on AIX. Did you try just getting a copy
>>> of the full hotspot library and running its configure on AIX to see if
>>> harfbuzz can work out which options it wants there ? Obviously
>>> I did not try that since I don't have AIX. Steven Loomis of IBM
>>> who submitted the JEP should be able to help with a lot of this.
>>>
>>> -phil.
>>>
>>> On 12/8/15, 10:50 AM, Volker Simonis wrote:
>>> > Hi,
>>> >
>>> > the integration of harfbuzz broke our AIX build because there's no
>>> > implementation available for the hb_atomic macros in
>>> > hb-atomic-private.hh. I've fixed that locally but still get a crash
>>> > when running a simple AWT program (even with
>>> > -Dsun.font.layoutengine=icu).
>>> >
>>> > I'm curretnly debugging the problem, but I have some general questions:
>>> >
>>> > 1. Do we really need the multi-threaded features of harfbuzz in OpenJDK?
>>> >
>>> > 2. Why does hurbuzz require these synchronization macros? From a first
>>> > glance it doesn't seem to use multiple threads by itself. Does it have
>>> > some global data structures which it needs to protect if harfbuzz is
>>> > called from various threads?
>>> >
>>> > 3. Is there a way to test the hurfbuzz engine on a new platform? I saw
>>> > the new test TestLayoutVsICU.java but it is marked as "manual" and it
>>> > seems to require external fonts (at least some of which seem to be
>>> > freely available). Could you please provide at least a minimal
>>> > description on how this test can be run?
>>> >
>>> > 4. Is there a way to test that the implementation of the hb_atomic
>>> > macros in hb-atomic-private.hh is correct (i.e. a way to stress
>>> > harfbuzz from multiple threads)? I think this is important as I
>>> > couldn't find a good description of the requirements for the atomic
>>> > macros and on weak memory model architectures we should really get
>>> > this right. For example there's no description of which fences are
>>> > required around the various atomic operations. Getting this right
>>> > across all platforms in the HotSpot (see
>>> > hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp) is already hard
>>> > enough so I'm a little concerned that we are now introducing similar
>>> > primitives in the class library.
>>> >
>>> > Thank you and best regards,
>>> > Volker
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151210/fa09beb3/attachment.html>

From behdad at google.com  Thu Dec 10 16:45:32 2015
From: behdad at google.com (Behdad Esfahbod)
Date: Thu, 10 Dec 2015 17:45:32 +0100
Subject: [OpenJDK 2D-Dev] Question regarding the integration of harfbuzz
 (JEP 258)
In-Reply-To: <CA+3eh109hpcmg816+9K0gffzjxpa3NRazW=ZSJFko7a3v0Tu+A@mail.gmail.com>
References: <56685EA9.8020704@oracle.com> <56685F3D.9000607@oracle.com>
	<D6F95352-C873-4C54-AC90-08A4E3BBB305@icu-project.org>
	<CA+3eh12V-G2L4uc5G=Yj75tG_KYUDDiud6zpYxwSHJ0VjC1QPA@mail.gmail.com>
	<CAOY=jUQKRUSdukaRHQ60r_+hVw6=z=nr1sRjB+OwkXx49nMO2A@mail.gmail.com>
	<CAOY=jUTkf3Y4jjqsSbx8ErgiBNhRQvjPSVETbOVqUa9ABFshAg@mail.gmail.com>
	<CA+3eh109hpcmg816+9K0gffzjxpa3NRazW=ZSJFko7a3v0Tu+A@mail.gmail.com>
Message-ID: <CAOY=jUQvoAXsdAa_7+45K3-ZqEK4XzrOnhDVDG48e7h9k3rrUg@mail.gmail.com>

Thanks Volker!

On Thu, Dec 10, 2015 at 5:12 PM, Volker Simonis <volker.simonis at gmail.com>
wrote:


> And now I see that you've already pushed the change! Thanks a lot. I'd
> only like to suggest the following minor enhancement to my initial change.
> It restricts the change to the case where HarfBuzz will be compiled with
> IBM's xlC compiler because it uses xlC compiler intrinsics. I know there
> are people out there who package open source software for AIX but they
> usually compile the whole toolchain with GCC. This minor addition will
> protect them from running into compile errors if they should ever try to
> compile HarfBuzz with GCC on AIX.
>

Pushed up!  Though, users with gcc probably will have
the HAVE_INTEL_ATOMIC_PRIMITIVES branch kick in and the AIX branch not
exercised.  But the fix is good so pushed.

Cheers,
behdad



> It would be great if you could add that as well to the upstream version.
>
> I will then update my OpenJDK patch to contain exactly your "shuffeled"
> upstream version so we don't get any problems when merging from upstream in
> the future.
>
> Thanks a lot once again,
> Volker
>
>
> diff -r fd95f33023e9
> src/java.desktop/share/native/libfontmanager/harfbuzz/hb-atomic-private.hh
> ---
> a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-atomic-private.hh
> Thu Dec 10 12:13:22 2015 +0100
> +++
> b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-atomic-private.hh
> Thu Dec 10 16:55:58 2015 +0100
> @@ -119,7 +119,7 @@
>  #define hb_atomic_ptr_impl_cmpexch(P,O,N)       ( ({__machine_rw_barrier
> ();}), atomic_cas_ptr ((void **) (P), (void *) (O), (void *) (N)) == (void
> *) (O) ? true : false)
>
>
> -#elif !defined(HB_NO_MT) && defined(_AIX)
> +#elif !defined(HB_NO_MT) && defined(_AIX) && defined(__IBMCPP__)
>
>  #include <builtins.h>
>
>
>
> On Thu, Dec 10, 2015 at 3:55 PM, Behdad Esfahbod <behdad at google.com>
> wrote:
>
>> Slightly shuffled patch was committed upstream:
>>
>> https://github.com/behdad/harfbuzz/commit/70b33edae7c8b9c031b83c95f00cb383789f1041
>>
>> Thanks,
>> behdad
>>
>>
>> On Thu, Dec 10, 2015 at 2:36 PM, Behdad Esfahbod <behdad at google.com>
>> wrote:
>>
>>> Hi Volker, Steven,
>>>
>>> I'd happily take AIX atomic primitive patch for HarfBuzz.  Yes, github
>>> Pull-Requests are fine.  As you correctly identified, HarfBuzz uses atomic
>>> ops and mutexes to synchronize access to global data as well as
>>> reference-counting from multiple threads, even though it doesn't uses
>>> threads itself.
>>>
>>> Does AIX use pthread for threading?  I can definitely add a threading
>>> stress-test to HarfBuzz.  I definitely should.  Filed here:
>>>
>>>   https://github.com/behdad/harfbuzz/issues/195
>>>
>>> Thanks,
>>> behdad
>>>
>>> On Thu, Dec 10, 2015 at 2:27 PM, Volker Simonis <
>>> volker.simonis at gmail.com> wrote:
>>>
>>>> Hi Steven,
>>>>
>>>> thanks for your response.
>>>>
>>>> On Thu, Dec 10, 2015 at 1:44 AM, Steven R. Loomis <srl at icu-project.org>
>>>> wrote:
>>>>
>>>>> Volker,
>>>>>  0. I?d like to see what the crashing stack frame is when NOT on
>>>>> harfbuzz, because there should be no change.
>>>>>
>>>>>
>>>> This was another problem. Please see my previous mail in this thread
>>>> where I've described the cause in more detail.
>>>>
>>>>
>>>>>  1. Phil addressed this one
>>>>>
>>>>>  2. I will take a look on AIX. I?ll see if I can build Harfbuzz itself
>>>>> on AIX at first.
>>>>>
>>>>>
>>>> I've fixed it now and just send around a request for review:
>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2015-December/006065.html
>>>>
>>>> The mail contains a link to the bug and the patch which fixes it.
>>>>
>>>> I also want to contribute this to harfbuzz. Is it OK to send a pull
>>>> request to https://github.com/behdad/harfbuzz ?
>>>>
>>>>  3. Yes, I?ll work on putting some docs together for that test.
>>>>> Actually, other tests such as the Font2DTest  would be a good test. Or, any
>>>>> text in a complex script such as Hindi.
>>>>>
>>>>>
>>>> That would be great. For now, the Font2DTest runs without a problem
>>>> with harfbuzz on AIX (and linux/ppc64).
>>>>
>>>>
>>>>>  4. I?m not sure. A threaded stress test would be good.  Perhaps
>>>>> Harfbuzz-in-JDK could leverage the
>>>>> hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp you mentioned.
>>>>>
>>>>>  Behdad - file is here
>>>>> http://hg.openjdk.java.net/jdk9/client/hotspot/file/c8e212fb27d0/src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp
>>>>>  - any comments on this or other items?
>>>>>
>>>>>
>>>> That sounds like a good idea but unfortunately the hotspot primitives
>>>> are in a different repository (source-code wise) and in a different library
>>>> (i.e. libjvm.so) which doesn't export them. So the best we can do for now
>>>> would be to copy the missing parts over to the jdk repository (and that's
>>>> actually what I've done now for the AIX version of the primitives).
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>
>>>>> -s
>>>>>
>>>>>
>>>>> -------- Original Message -------- Subject: Re: [OpenJDK 2D-Dev]
>>>>> Question regarding the integration of harfbuzz (JEP 258) Date: Wed,
>>>>> 09 Dec 2015 09:02:33 -0800 From: Philip Race <philip.race at oracle.com>
>>>>> <philip.race at oracle.com> Organization: Oracle Corporation To:
>>>>> 2d-dev at openjdk.java.net
>>>>>
>>>>>
>>>>> Hi Volker,
>>>>>
>>>>> Running with ICU should stop harfbuzz use completely so if
>>>>> you are still seeing a crash, perhaps it is due to something else entirely.
>>>>> Especially since a "simple AWT program" should not load layout anyway.
>>>>> There was a fair amount of new and changed code pushed recently ...
>>>>>
>>>>> Yes, we need to run harfbuzz in multiple concurrent threads in the JDK.
>>>>> A single threaded lock on harfbuzz would throttle text operations.
>>>>> I suppose it is possible that we do not strictly need it as we currently
>>>>> create a
>>>>> new harfbuzz "instance" each time we go to invoke layout but that
>>>>> is something that at least theoretically could change.
>>>>>
>>>>> The approach to synchronization is all from up-stream harfbuzz.
>>>>> The harfbuzz mailing list might be the place to discuss that.
>>>>> I'd expect it does work on AIX as a principal driver here is that
>>>>> the IBM sponsored ICU project has deprecated its layout engine
>>>>> and IBM/ICU are moving to harfbuzz so I'd be somewhat astonished
>>>>> if they haven't yet tried it on AIX. Did you try just getting a copy
>>>>> of the full hotspot library and running its configure on AIX to see if
>>>>> harfbuzz can work out which options it wants there ? Obviously
>>>>> I did not try that since I don't have AIX. Steven Loomis of IBM
>>>>> who submitted the JEP should be able to help with a lot of this.
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 12/8/15, 10:50 AM, Volker Simonis wrote:
>>>>> > Hi,
>>>>> >
>>>>> > the integration of harfbuzz broke our AIX build because there's no
>>>>> > implementation available for the hb_atomic macros in
>>>>> > hb-atomic-private.hh. I've fixed that locally but still get a crash
>>>>> > when running a simple AWT program (even with
>>>>> > -Dsun.font.layoutengine=icu).
>>>>> >
>>>>> > I'm curretnly debugging the problem, but I have some general questions:
>>>>> >
>>>>> > 1. Do we really need the multi-threaded features of harfbuzz in OpenJDK?
>>>>> >
>>>>> > 2. Why does hurbuzz require these synchronization macros? From a first
>>>>> > glance it doesn't seem to use multiple threads by itself. Does it have
>>>>> > some global data structures which it needs to protect if harfbuzz is
>>>>> > called from various threads?
>>>>> >
>>>>> > 3. Is there a way to test the hurfbuzz engine on a new platform? I saw
>>>>> > the new test TestLayoutVsICU.java but it is marked as "manual" and it
>>>>> > seems to require external fonts (at least some of which seem to be
>>>>> > freely available). Could you please provide at least a minimal
>>>>> > description on how this test can be run?
>>>>> >
>>>>> > 4. Is there a way to test that the implementation of the hb_atomic
>>>>> > macros in hb-atomic-private.hh is correct (i.e. a way to stress
>>>>> > harfbuzz from multiple threads)? I think this is important as I
>>>>> > couldn't find a good description of the requirements for the atomic
>>>>> > macros and on weak memory model architectures we should really get
>>>>> > this right. For example there's no description of which fences are
>>>>> > required around the various atomic operations. Getting this right
>>>>> > across all platforms in the HotSpot (see
>>>>> > hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp) is already hard
>>>>> > enough so I'm a little concerned that we are now introducing similar
>>>>> > primitives in the class library.
>>>>> >
>>>>> > Thank you and best regards,
>>>>> > Volker
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151210/a80b8f59/attachment.html>

From volker.simonis at gmail.com  Thu Dec 10 17:38:11 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 10 Dec 2015 18:38:11 +0100
Subject: [OpenJDK 2D-Dev] RFR(S): 8145077: AIX: fix harfbuzz support
In-Reply-To: <CA+3eh11B-RN03Hxa7NnicVVteXeh_=1byg9cF7Y8amemjg+9zw@mail.gmail.com>
References: <CA+3eh11B-RN03Hxa7NnicVVteXeh_=1byg9cF7Y8amemjg+9zw@mail.gmail.com>
Message-ID: <CA+3eh11E3W=aPLZqcMj3=q54qtU9EgRT7WFveKbpCGOO5RmUCg@mail.gmail.com>

Hi,

here's a slightly updated version of my webrev which is now identical
to the version which has just been checked-in into the HarfBuzz
upstream repository (thanks to Behdad):

http://cr.openjdk.java.net/~simonis/webrevs/2015/8145077.v1

Except some whitespace changes, the only real difference is that the
AIX atomic intrinsics are now additionally guarded by a compiler check
which ensures that they only get compiled with IBM's xlC compiler.

Regards,
Volker


On Thu, Dec 10, 2015 at 2:13 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Hi,
>
> could somebody please review this AIX-only fix which adds the harfbuzz
> atomic primitives for AIX:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8145077/
> https://bugs.openjdk.java.net/browse/JDK-8145077
>
> I plan to also submit this patch upstream to the harfbuzz project to
> minimize the diffs between the upstream and the OpenJDK version.
>
> Notice that although this is a client patch I plan to push this
> directly to jdk9-dev because it fixes a build failure and I don't want
> to wait for the next round-trip trough jdk9-client.
>
> Thank you and best regards,
> Volker


From philip.race at oracle.com  Thu Dec 10 18:59:59 2015
From: philip.race at oracle.com (Phil Race)
Date: Thu, 10 Dec 2015 10:59:59 -0800
Subject: [OpenJDK 2D-Dev] RFR(S): 8145077: AIX: fix harfbuzz support
In-Reply-To: <CA+3eh11E3W=aPLZqcMj3=q54qtU9EgRT7WFveKbpCGOO5RmUCg@mail.gmail.com>
References: <CA+3eh11B-RN03Hxa7NnicVVteXeh_=1byg9cF7Y8amemjg+9zw@mail.gmail.com>
	<CA+3eh11E3W=aPLZqcMj3=q54qtU9EgRT7WFveKbpCGOO5RmUCg@mail.gmail.com>
Message-ID: <5669CBAF.2010108@oracle.com>


Should the compiler check go upstream too ?
It is likely to get lost if it does not.
Otherwise looks good. I've added noreg-other to the bug.
Is there an "aix" label in use ?

-phil.

On 12/10/2015 09:38 AM, Volker Simonis wrote:
> Hi,
>
> here's a slightly updated version of my webrev which is now identical
> to the version which has just been checked-in into the HarfBuzz
> upstream repository (thanks to Behdad):
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8145077.v1
>
> Except some whitespace changes, the only real difference is that the
> AIX atomic intrinsics are now additionally guarded by a compiler check
> which ensures that they only get compiled with IBM's xlC compiler.
>
> Regards,
> Volker
>
>
> On Thu, Dec 10, 2015 at 2:13 PM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>> Hi,
>>
>> could somebody please review this AIX-only fix which adds the harfbuzz
>> atomic primitives for AIX:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8145077/
>> https://bugs.openjdk.java.net/browse/JDK-8145077
>>
>> I plan to also submit this patch upstream to the harfbuzz project to
>> minimize the diffs between the upstream and the OpenJDK version.
>>
>> Notice that although this is a client patch I plan to push this
>> directly to jdk9-dev because it fixes a build failure and I don't want
>> to wait for the next round-trip trough jdk9-client.
>>
>> Thank you and best regards,
>> Volker



From bourges.laurent at gmail.com  Thu Dec 10 21:14:07 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 10 Dec 2015 22:14:07 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <5668C6F8.4020700@oracle.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
	<566219C4.303@oracle.com> <56621A48.7020406@oracle.com>
	<56663D94.6040304@oracle.com>
	<CAKjRUT7u+wm5x5eyG5o-3krMWtNwD3f_jc40zos4Gn0-CpTz9w@mail.gmail.com>
	<566763C2.7070800@oracle.com> <56682555.9020809@oracle.com>
	<CAKjRUT7qLSdYaBvN5Ci6HouP06iUJvefbGAYGikJF_Z4s4kNrg@mail.gmail.com>
	<56689D97.3070406@oracle.com>
	<CAKjRUT6wdiuSakCpLt8dtKX_upfYUY76Mrb+a7T-WdZF332KFg@mail.gmail.com>
	<5668ABDF.7030002@oracle.com>
	<CAKjRUT6dCt7tsONipDatV=_3ANHO_7WsZcENN0JJQjDOYGAJ+g@mail.gmail.com>
	<5668C6F8.4020700@oracle.com>
Message-ID: <CAKjRUT7D8K=XShX+tSddscM+CC51H8Nk=Wqz+WFF4Lh267aFwg@mail.gmail.com>

Hi Jim,

Here is the updated webrev:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.3/

The fix looks correct, but one thing I would tend to do for robustness is
> that in an error case, rather than duplicate the logic that was skipped
> (which can get out of date if we later change how the bounds*Y variables
> are calculated), I would just hardcode the bounds*Y variables to the worst
> case min/max so that we do a complete fill on the variables.  For error
> cases it is less interesting to optimize out every memory store and more
> interesting to make sure that we robustly restore the state.  Another
> option would be to move the bounds logic to a separate function that is
> called in both the error and the success cases?
>

Fixed: I agree it is better to clear completely bucket arrays.


> For the test, you can have multiple test tags and include an @ignore so
> that the primary tests are run every time and the ones after the ignore are
> only run if someone runs with "-ignore:run".  That makes them runnable from
> the command line without having to edit the test:
>
> @run main/othervm -mx512m CrashTest
> @ignore tests that take a long time
> @run main/othervm -mx512m CrashTest -slow
>
> The first line would be run in all cases, the second line would only be
> run if they specify "-ignore:run" on the command line.
>

Fixed: I adopted your approach and it works well:

----------messages:(3/129)----------
command: main -mx512m CrashTest
reason: User specified action: run main/othervm -mx512m CrashTest
elapsed time (seconds): 8.318

----------messages:(3/150)----------
command: main -ms4g -mx4g CrashTest -slow
reason: User specified action: run main/othervm -ms4g -mx4g CrashTest -slow
elapsed time (seconds): 49.777


> The only down side is that the tests after the @ignore are shown on the
> final statistics as "errors" which seems kind of melodramatic, but that's
> why the "-ignore:quiet" option exists.  There are quite a few tests in the
> java hierarchy with an @ignore tag, though, often talking about extreme
> memory requirements so this is nothing new.  This would be the first in the
> sun/java2d hierarchy, though...
>

I enabled also the huge image test that consumes ~5Gb and it passes on my
laptop (16Gb).

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151210/fea36387/attachment.html>

From philip.race at oracle.com  Thu Dec 10 21:28:11 2015
From: philip.race at oracle.com (Philip Race)
Date: Thu, 10 Dec 2015 13:28:11 -0800
Subject: [OpenJDK 2D-Dev] <OpenJDK 2D-Dev> Review request for
 JDK-8143562: JPEG reader returns null for getRawImageType()
In-Reply-To: <5667D8D6.3030803@oracle.com>
References: <45125a5d-a274-4321-9510-dc0e8774d505@default>
	<5667D8D6.3030803@oracle.com>
Message-ID: <5669EE6B.8080802@oracle.com>

The quoted code comment is essentially disclaiming the spec comment.
And the spec. comment is misleading in that it strongly suggests 
getRawImageType
will hand you an ImageTypeSpecifier representing YCbCr when in fact it 
does not.

In fact all these comments and behaviours together seem to suggest that 
there
isn't a consistent view of what should happen here.
- one says we can return something that represents YCbCr
- another says don't add it to the returned list of types because we 
can't support this raw type after all.
- the spec says return something (anything!) no matter how dissimilar 
(implied
    by there being at least one (a non-null return)).

Basically that seems to be all the options except supporting it.
All of these need to line up and agree.

So I think we need to update the spec. below to say something like
"Returns an |ImageTypeSpecifier| indicating the |SampleModel| and 
|ColorModel|
which most closely represents the "raw" internal format of the image.
If there is no close match then a type which preserves the most
information from the image should be returned."

-phil

On 12/8/15, 11:31 PM, prasanta sadhukhan wrote:
> The fix looks good to me.
> The spec says "Returns an |ImageTypeSpecifier| indicating the 
> |SampleModel| and |ColorModel| which most closely represents the "raw" 
> internal format of the image. For example, for a JPEG image the raw 
> type might have a YCbCr color space even though the image would 
> conventionally be transformed into an RGB color space prior to display."
> Also,
> private Iterator<ImageTypeSpecifier>  getImageTypesOnThread(int imageIndex)adds RGB for YcbCr raw type
> case JPEG.JCS_YCbCr:
>   832             // As there is no YCbCr ColorSpace, we can't support
>   833             // the raw type.
>   834
>   835             // due to 4705399, use RGB as default in order to avoid
>   836             // slowing down of drawing operations with result image.
>   837             list.add(getImageType(JPEG.JCS_RGB));
>
>
> Regards
> Prasanta
> On 12/1/2015 3:42 PM, Jayathirth D V wrote:
>>
>> Hi,
>>
>> _Please review following fix in JDK9:_
>>
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8143562
>>
>> Webrev : http://cr.openjdk.java.net/~jdv/8143562/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Ejdv/8143562/webrev.00/>
>>
>> Issue : We are getting null for ImageTypeSpecifier when we use 
>> getRawImageType() API for YCbCr Image.
>>
>> Root cause : When colorspace is YCbCr, there is no condition to 
>> create ImageTypeSpecifier in produce() function
>>
>> Solution : Since we add RGB as default ImageType for YCbCr colorspace 
>> in getImageTypes() API. Followed same approach
>>
>>                     and considering it as RGB in getRawImageType().
>>
>> Thanks,
>>
>> Jay
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151210/78890eda/attachment.html>

From james.graham at oracle.com  Thu Dec 10 22:26:16 2015
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 10 Dec 2015 14:26:16 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <CAKjRUT7D8K=XShX+tSddscM+CC51H8Nk=Wqz+WFF4Lh267aFwg@mail.gmail.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
	<566219C4.303@oracle.com> <56621A48.7020406@oracle.com>
	<56663D94.6040304@oracle.com>
	<CAKjRUT7u+wm5x5eyG5o-3krMWtNwD3f_jc40zos4Gn0-CpTz9w@mail.gmail.com>
	<566763C2.7070800@oracle.com> <56682555.9020809@oracle.com>
	<CAKjRUT7qLSdYaBvN5Ci6HouP06iUJvefbGAYGikJF_Z4s4kNrg@mail.gmail.com>
	<56689D97.3070406@oracle.com>
	<CAKjRUT6wdiuSakCpLt8dtKX_upfYUY76Mrb+a7T-WdZF332KFg@mail.gmail.com>
	<5668ABDF.7030002@oracle.com>
	<CAKjRUT6dCt7tsONipDatV=_3ANHO_7WsZcENN0JJQjDOYGAJ+g@mail.gmail.com>
	<5668C6F8.4020700@oracle.com>
	<CAKjRUT7D8K=XShX+tSddscM+CC51H8Nk=Wqz+WFF4Lh267aFwg@mail.gmail.com>
Message-ID: <5669FC08.7030907@oracle.com>

Looks good...

I ran it both ways and got similar run times...

		...jim

On 12/10/15 1:14 PM, Laurent Bourg?s wrote:
> Hi Jim,
>
> Here is the updated webrev:
> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.3/
>
>     The fix looks correct, but one thing I would tend to do for
>     robustness is that in an error case, rather than duplicate the logic
>     that was skipped (which can get out of date if we later change how
>     the bounds*Y variables are calculated), I would just hardcode the
>     bounds*Y variables to the worst case min/max so that we do a
>     complete fill on the variables.  For error cases it is less
>     interesting to optimize out every memory store and more interesting
>     to make sure that we robustly restore the state.  Another option
>     would be to move the bounds logic to a separate function that is
>     called in both the error and the success cases?
>
>
> Fixed: I agree it is better to clear completely bucket arrays.
>
>     For the test, you can have multiple test tags and include an @ignore
>     so that the primary tests are run every time and the ones after the
>     ignore are only run if someone runs with "-ignore:run".  That makes
>     them runnable from the command line without having to edit the test:
>
>     @run main/othervm -mx512m CrashTest
>     @ignore tests that take a long time
>     @run main/othervm -mx512m CrashTest -slow
>
>     The first line would be run in all cases, the second line would only
>     be run if they specify "-ignore:run" on the command line.
>
>
> Fixed: I adopted your approach and it works well:
>
> ----------messages:(3/129)----------
> command: main -mx512m CrashTest
> reason: User specified action: run main/othervm -mx512m CrashTest
> elapsed time (seconds): 8.318
>
> ----------messages:(3/150)----------
> command: main -ms4g -mx4g CrashTest -slow
> reason: User specified action: run main/othervm -ms4g -mx4g CrashTest -slow
> elapsed time (seconds): 49.777
>
>
>     The only down side is that the tests after the @ignore are shown on
>     the final statistics as "errors" which seems kind of melodramatic,
>     but that's why the "-ignore:quiet" option exists.  There are quite a
>     few tests in the java hierarchy with an @ignore tag, though, often
>     talking about extreme memory requirements so this is nothing new.
>     This would be the first in the sun/java2d hierarchy, though...
>
>
> I enabled also the huge image test that consumes ~5Gb and it passes on
> my laptop (16Gb).
>
> Cheers,
> Laurent


From bourges.laurent at gmail.com  Thu Dec 10 22:51:52 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 10 Dec 2015 23:51:52 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <5669FC08.7030907@oracle.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
	<566219C4.303@oracle.com> <56621A48.7020406@oracle.com>
	<56663D94.6040304@oracle.com>
	<CAKjRUT7u+wm5x5eyG5o-3krMWtNwD3f_jc40zos4Gn0-CpTz9w@mail.gmail.com>
	<566763C2.7070800@oracle.com> <56682555.9020809@oracle.com>
	<CAKjRUT7qLSdYaBvN5Ci6HouP06iUJvefbGAYGikJF_Z4s4kNrg@mail.gmail.com>
	<56689D97.3070406@oracle.com>
	<CAKjRUT6wdiuSakCpLt8dtKX_upfYUY76Mrb+a7T-WdZF332KFg@mail.gmail.com>
	<5668ABDF.7030002@oracle.com>
	<CAKjRUT6dCt7tsONipDatV=_3ANHO_7WsZcENN0JJQjDOYGAJ+g@mail.gmail.com>
	<5668C6F8.4020700@oracle.com>
	<CAKjRUT7D8K=XShX+tSddscM+CC51H8Nk=Wqz+WFF4Lh267aFwg@mail.gmail.com>
	<5669FC08.7030907@oracle.com>
Message-ID: <CAKjRUT6EZw=LENJ0cCwU=iijYkRYaXFo6x1HpL41Ukhr7n3Jbw@mail.gmail.com>

Excellent !

It seems to me that my bug sprint on Marlin is done except the new one
created as a follow-up.

Please push them all !

I will now work on other improvements:
- Png compression (in progress)
- handling NaN / huge coords in Marlin

Thanks for all reviews,

Cheers,
Laurent
Le 10 d?c. 2015 23:26, "Jim Graham" <james.graham at oracle.com> a ?crit :

> Looks good...
>
> I ran it both ways and got similar run times...
>
>                 ...jim
>
> On 12/10/15 1:14 PM, Laurent Bourg?s wrote:
>
>> Hi Jim,
>>
>> Here is the updated webrev:
>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.3/
>>
>>     The fix looks correct, but one thing I would tend to do for
>>     robustness is that in an error case, rather than duplicate the logic
>>     that was skipped (which can get out of date if we later change how
>>     the bounds*Y variables are calculated), I would just hardcode the
>>     bounds*Y variables to the worst case min/max so that we do a
>>     complete fill on the variables.  For error cases it is less
>>     interesting to optimize out every memory store and more interesting
>>     to make sure that we robustly restore the state.  Another option
>>     would be to move the bounds logic to a separate function that is
>>     called in both the error and the success cases?
>>
>>
>> Fixed: I agree it is better to clear completely bucket arrays.
>>
>>     For the test, you can have multiple test tags and include an @ignore
>>     so that the primary tests are run every time and the ones after the
>>     ignore are only run if someone runs with "-ignore:run".  That makes
>>     them runnable from the command line without having to edit the test:
>>
>>     @run main/othervm -mx512m CrashTest
>>     @ignore tests that take a long time
>>     @run main/othervm -mx512m CrashTest -slow
>>
>>     The first line would be run in all cases, the second line would only
>>     be run if they specify "-ignore:run" on the command line.
>>
>>
>> Fixed: I adopted your approach and it works well:
>>
>> ----------messages:(3/129)----------
>> command: main -mx512m CrashTest
>> reason: User specified action: run main/othervm -mx512m CrashTest
>> elapsed time (seconds): 8.318
>>
>> ----------messages:(3/150)----------
>> command: main -ms4g -mx4g CrashTest -slow
>> reason: User specified action: run main/othervm -ms4g -mx4g CrashTest
>> -slow
>> elapsed time (seconds): 49.777
>>
>>
>>     The only down side is that the tests after the @ignore are shown on
>>     the final statistics as "errors" which seems kind of melodramatic,
>>     but that's why the "-ignore:quiet" option exists.  There are quite a
>>     few tests in the java hierarchy with an @ignore tag, though, often
>>     talking about extreme memory requirements so this is nothing new.
>>     This would be the first in the sun/java2d hierarchy, though...
>>
>>
>> I enabled also the huge image test that consumes ~5Gb and it passes on
>> my laptop (16Gb).
>>
>> Cheers,
>> Laurent
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151210/7a590bd2/attachment.html>

From philip.race at oracle.com  Thu Dec 10 23:18:15 2015
From: philip.race at oracle.com (Phil Race)
Date: Thu, 10 Dec 2015 15:18:15 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test
In-Reply-To: <CAKjRUT6EZw=LENJ0cCwU=iijYkRYaXFo6x1HpL41Ukhr7n3Jbw@mail.gmail.com>
References: <CAKjRUT7g_yyCRbw8NOF4rckf2Uh6vFR-y-qzT8D02TDZa1g0SA@mail.gmail.com>
	<56609F2B.3020101@oracle.com>
	<CAKjRUT40Nsopn0qYZEbtmwB71TxpCAUTpzDef=3pug0ZFBNkZw@mail.gmail.com>
	<566219C4.303@oracle.com> <56621A48.7020406@oracle.com>
	<56663D94.6040304@oracle.com>
	<CAKjRUT7u+wm5x5eyG5o-3krMWtNwD3f_jc40zos4Gn0-CpTz9w@mail.gmail.com>
	<566763C2.7070800@oracle.com> <56682555.9020809@oracle.com>
	<CAKjRUT7qLSdYaBvN5Ci6HouP06iUJvefbGAYGikJF_Z4s4kNrg@mail.gmail.com>
	<56689D97.3070406@oracle.com>
	<CAKjRUT6wdiuSakCpLt8dtKX_upfYUY76Mrb+a7T-WdZF332KFg@mail.gmail.com>
	<5668ABDF.7030002@oracle.com>
	<CAKjRUT6dCt7tsONipDatV=_3ANHO_7WsZcENN0JJQjDOYGAJ+g@mail.gmail.com>
	<5668C6F8.4020700@oracle.com>
	<CAKjRUT7D8K=XShX+tSddscM+CC51H8Nk=Wqz+WFF4Lh267aFwg@mail.gmail.com>
	<5669FC08.7030907@oracle.com>
	<CAKjRUT6EZw=LENJ0cCwU=iijYkRYaXFo6x1HpL41Ukhr7n3Jbw@mail.gmail.com>
Message-ID: <566A0837.4080703@oracle.com>


+1 on on the v3 webrev ..

-phil.


On 12/10/2015 02:51 PM, Laurent Bourg?s wrote:
>
> Excellent !
>
> It seems to me that my bug sprint on Marlin is done except the new one 
> created as a follow-up.
>
> Please push them all !
>
> I will now work on other improvements:
> - Png compression (in progress)
> - handling NaN / huge coords in Marlin
>
> Thanks for all reviews,
>
> Cheers,
> Laurent
>
> Le 10 d?c. 2015 23:26, "Jim Graham" <james.graham at oracle.com 
> <mailto:james.graham at oracle.com>> a ?crit :
>
>     Looks good...
>
>     I ran it both ways and got similar run times...
>
>                     ...jim
>
>     On 12/10/15 1:14 PM, Laurent Bourg?s wrote:
>
>         Hi Jim,
>
>         Here is the updated webrev:
>         http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.3/
>         <http://cr.openjdk.java.net/%7Elbourges/marlin/marlin-8144446.3/>
>
>             The fix looks correct, but one thing I would tend to do for
>             robustness is that in an error case, rather than duplicate
>         the logic
>             that was skipped (which can get out of date if we later
>         change how
>             the bounds*Y variables are calculated), I would just
>         hardcode the
>             bounds*Y variables to the worst case min/max so that we do a
>             complete fill on the variables.  For error cases it is less
>             interesting to optimize out every memory store and more
>         interesting
>             to make sure that we robustly restore the state. Another
>         option
>             would be to move the bounds logic to a separate function
>         that is
>             called in both the error and the success cases?
>
>
>         Fixed: I agree it is better to clear completely bucket arrays.
>
>             For the test, you can have multiple test tags and include
>         an @ignore
>             so that the primary tests are run every time and the ones
>         after the
>             ignore are only run if someone runs with "-ignore:run".
>         That makes
>             them runnable from the command line without having to edit
>         the test:
>
>             @run main/othervm -mx512m CrashTest
>             @ignore tests that take a long time
>             @run main/othervm -mx512m CrashTest -slow
>
>             The first line would be run in all cases, the second line
>         would only
>             be run if they specify "-ignore:run" on the command line.
>
>
>         Fixed: I adopted your approach and it works well:
>
>         ----------messages:(3/129)----------
>         command: main -mx512m CrashTest
>         reason: User specified action: run main/othervm -mx512m CrashTest
>         elapsed time (seconds): 8.318
>
>         ----------messages:(3/150)----------
>         command: main -ms4g -mx4g CrashTest -slow
>         reason: User specified action: run main/othervm -ms4g -mx4g
>         CrashTest -slow
>         elapsed time (seconds): 49.777
>
>
>             The only down side is that the tests after the @ignore are
>         shown on
>             the final statistics as "errors" which seems kind of
>         melodramatic,
>             but that's why the "-ignore:quiet" option exists.  There
>         are quite a
>             few tests in the java hierarchy with an @ignore tag,
>         though, often
>             talking about extreme memory requirements so this is
>         nothing new.
>             This would be the first in the sun/java2d hierarchy, though...
>
>
>         I enabled also the huge image test that consumes ~5Gb and it
>         passes on
>         my laptop (16Gb).
>
>         Cheers,
>         Laurent
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151210/240449a7/attachment.html>

From philip.race at oracle.com  Thu Dec 10 23:38:47 2015
From: philip.race at oracle.com (Philip Race)
Date: Thu, 10 Dec 2015 15:38:47 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144445: Maximum size checking in Marlin
 ArrayCache utility methods is not optimal
In-Reply-To: <5668A649.1030403@oracle.com>
References: <CAKjRUT7=puzVxKiqEGoCae_QCcw6Nu-HBZa6LvmB=Uqcf0mcyA@mail.gmail.com>
	<56621E1A.1080602@oracle.com>
	<CAKjRUT4B2g+FPZKYHUfXipbBhQiAy9PFxEN2v2zvntb1LmVWGg@mail.gmail.com>
	<56662E11.8080408@oracle.com>
	<CAKjRUT49Sg7vvn1KtMUxx25ksmjRQ0CYcFT1auSVy3F9+bt3-A@mail.gmail.com>
	<5668A649.1030403@oracle.com>
Message-ID: <566A0D07.50000@oracle.com>

+1

-phil.

On 12/9/15, 2:08 PM, Jim Graham wrote:
> Looks good.
>
> And verified that the test fails before the fix and passes after...
>
>             ...jim
>
> On 12/9/15 1:38 PM, Laurent Bourg?s wrote:
>> Hi Jim,
>>
>> I took me some time to understand your detailled analysis and make a new
>> webrev:
>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144445.2/
>>
>> I think I adopted all your change proposals, see below:
>>
>>     In looking this over again I notice that really the exceptions are
>>     only thrown on "out of range" needSize values and they are probably
>>     always thrown in that case, but sometimes we only discover those
>>     range issues if other things fail and many of the tests that lead to
>>     getting to that statement may or may not operate correctly depending
>>     on whether they are dealing with a valid needSize (for instance
>>     testing against "< needSize" when needSize might be negative,
>>     etc.).  It makes verifying this code much more difficult due to
>>     having to deal with cases where multiple variables might be out of
>>     range when they are computed or compared against each other.  To
>>     that end, it might be more straightforward to simply test needSize
>>     at the top and then the rest of the function can know it is dealing
>>     with a proper value for needSize and only has to worry about
>>     returning a non-overflowing number.  Knowing that needSize is a
>>     valid number makes any computations with it or compares against it
>>     have fewer "failure conditions" to note and vet.
>>
>>
>> I followed your approach and I agree it is more clear.
>>
>>
>>     For example:
>>
>>     first function:
>>
>>     185-189 move to the top of the function and only test needSize and
>>     then later on line 177 we capture any overflow since we know that
>>     needSize cannot be negative as well.  180,182 are then sufficient to
>>     make sure that the value calculated in that case will be >= 
>> needSize.
>>
>>
>> Fixed.
>>
>>     second function:
>>
>>     215-220 also move to the top of that function and 214 (if it
>>     compares size in both cases) is sufficient to make sure we are
>>     returning a value >= needSize in all cases.  As it stands 210 and
>>     212 could be computing random values and the tests at 214 and later
>>     are no longer complicated by having to consider the case that
>>     needSize itself is wrong - they only have to deal with whether the
>>     returned size bumped out of range.
>>
>>
>> Fixed.
>>
>>     general note:
>>
>>     Also, "(longval < 0L || longval > MAX_INT)" can be calculated as
>>     "((longval >> 31) != 0)".
>>
>>
>> Thanks for the tip: I use it now.
>>
>>         I could also check size < 0L if you want but it is only 
>> possible if
>>         curSize < 0 (that should never happen) !
>>
>>
>>     That may be true at line 209, but then you test it against needSize
>>     and do more calculations where the new value of size depends only on
>>     needSize and so its dependence on curSize no longer offers any
>>     protection.  At 214 you might not be able to assert that size>=0 any
>>     more as a result.
>>
>>            That works.  I was thinking more along the lines of this
>>         which is more straightforward:
>>
>>
>>     try {
>>          do test;
>>          throw new RuntimeException("AIOBException not thrown");
>>     } catch (AIOBException e) (
>>          return;
>>     } catch (Throwable t) {
>>          throw new RuntimeException("Wrong exception (not AIOB) 
>> thrown", t);
>>     }
>>
>>
>> Fixed.
>>
>> Cheers,
>> Laurent


From philip.race at oracle.com  Thu Dec 10 23:41:54 2015
From: philip.race at oracle.com (Philip Race)
Date: Thu, 10 Dec 2015 15:41:54 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144654: Improve Marlin logging
In-Reply-To: <CAKjRUT5ywmsFAZ4Cu1rsESsb-DZ174BoZMz+AmTNYHqwg-WLVQ@mail.gmail.com>
References: <CAKjRUT51G2n6=U1uJx+_H_ZqYjkbWKp4obwktWxEzyFZOW-zwA@mail.gmail.com>
	<56621704.2010302@oracle.com> <56621C42.8050807@oracle.com>
	<CAKjRUT7evVLiTUzVMDYVpJw1Mfevb+gPuBgR3bCm=fwejooZLg@mail.gmail.com>
	<56660D03.5000302@oracle.com>
	<CAKjRUT5ywmsFAZ4Cu1rsESsb-DZ174BoZMz+AmTNYHqwg-WLVQ@mail.gmail.com>
Message-ID: <566A0DC2.8030801@oracle.com>

+1

-phil.


On 12/8/15, 12:03 AM, Laurent Bourg?s wrote:
>
> Jim,
>
> > Looks good.
> >
> > Is there some way to reduce the impact of not hard-coding doMonitors 
> for future benefit?  Or is that constant only for debugging modifications?
>
> Durin Marlin development, I occasionally use doMonitor to get internal 
> timings so it is a developper feature that should remain confidential 
> but interesting to keep in the code (disabled by default).
>
> The JMH perfasm profiler is better as it provides more accurate 
> timings and lower overhead!
>
> Laurent
>
> > On 12/5/15 8:54 AM, Laurent Bourg?s wrote:
> >>
> >> Phil & Jim,
> >>
> >> Here is the updated webrev:
> >> http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144654.1/ 
> <http://cr.openjdk.java.net/%7Elbourges/marlin/marlin-8144654.1/>
> >>
> >> Changes:
> >> - isEnableLogs() renamed to isLoggingEnabled(); I used the convention
> >> "is<MemberName>" even if it is not english !
> >> - restored doMonitors to false (as it reduces the bytecode count for
> >> inlining)
> >>
> >> Comments below:
> >>
> >> 2015-12-05 0:05 GMT+01:00 Jim Graham <james.graham at oracle.com 
> <mailto:james.graham at oracle.com>
> >> <mailto:james.graham at oracle.com <mailto:james.graham at oracle.com>>>:
> >>
> >>
> >>     Perhaps "isLoggingEnabled()"?
> >>
> >>
> >> Fixed.
> >>
> >>
> >>     This turns a bunch of constants from having compile-time values to
> >>     run-time values so the javac compiler will no longer be able to
> >>     compile the code out of the classfiles.  On the other hand, the
> >>     fields are still final so the Hotspot compiler should still be able
> >>     to eliminate the associated code at run-time, so hopefully this had
> >>     no impact on performance?
> >>
> >>
> >> No
> >>
> >>
> >>
> >>     On 12/4/15 2:43 PM, Phil Race wrote:
> >>
> >>         139 public static boolean isEnableLogs() {
> >>         140 return getBoolean("sun.java2d.renderer.log", "false");
> >>         141 }
> >>
> >>         All of these begin with sun.java2d.renderer but they are 
> all marlin
> >>         specific.
> >>         I guess it is OK though if we expect that ultimately marlin is
> >>         the only
> >>         renderer.
> >>
> >>
> >> I can later rename all Marlin system properties at once to use the
> >> prefix "sun.java2d.marlin" if you prefer (already discussed?).
> >>
> >>
> >>         "isEnable" does not read well but I know that the same pattern
> >>         is used for
> >>         everything so I don't have a firm objection although the "is"
> >>         seems likeit
> >>         is could be removed in most cases. Some may need a "do" adding
> >>
> >>
> >> Fixed using Jim's proposal.
> >>
> >>
> >>         You have deleted getCallerInfo so probably you can close
> >> https://bugs.openjdk.java.net/browse/JDK-8144530 as a dup of
> >>         this bug.
> >>
> >>
> >> Done.
> >>
> >> Cheers,
> >> Laurent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151210/a213ef9c/attachment.html>

From bourges.laurent at gmail.com  Thu Dec 10 23:45:21 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 11 Dec 2015 00:45:21 +0100
Subject: [OpenJDK 2D-Dev] RFR 6488522: PNG writer should permit setting
 compression level and iDAT chunk maximum size
In-Reply-To: <566973A2.3000300@oracle.com>
References: <CAKjRUT4T7L8cK=SP0QM1LK-azLNexA0RNoq2FEFSdbSFetYr6g@mail.gmail.com>
	<56682A5E.6080904@oracle.com>
	<CAKjRUT5fu6fj1ugZ3Yf+C_RzNxRxqVyTb5my2GW5v=jr+n1+dA@mail.gmail.com>
	<566973A2.3000300@oracle.com>
Message-ID: <CAKjRUT71nwgQKLE0wVOw=7BTbjG2PLZzxwEY7UWuogR_nemx1w@mail.gmail.com>

Hi Sergey,

Here is the updated webrev:
http://cr.openjdk.java.net/~lbourges/png/PNGWriter-6488522.1/


> A few notes:
>  - Should PNGImageWriteParam.unsetCompression resets the compressionType
> to compressionTypes[0]?
>

Fixed.


>  - Is it necessary to copy the checks in PNGImageWriteParam from the
> parent? We can just call super() and expect that the parent class validate
> current state.
>

Agreed: I simply call super.getCompressionQualityXXX() before returning the
appropriate value.


> Yes, I could check that every png file is not zero-length or that better
>> compression gives smaller file size !
>>
>
> It would be good, because right now it check not all changes in the fix.
>

Fixed: I now check that better compression gives smaller file (but it may
be not always the case as some algorithms use several passes or an adaptive
strategy ...)


> However, my changes rely on the public Deflater API that supports
>> compression levels between 0 to 9.
>>
>> I suppose that this Deflater class is already covered by its own tests
>> so I would prefer leaving the test as it is (no verification):  if the
>> Deflater raises any RuntimeException, then the PNGWriterCompressionTest
>> will fail.
>>
>
> But this test is passed even for such fix:
>
> ---
> a/src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java
> Thu Dec 10 14:21:44 2015 +0300
> +++
> b/src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java
> Thu Dec 10 15:15:41 2015 +0300
> @@ -280,6 +280,7 @@
>          super();
>          this.canWriteProgressive = true;
>          this.locale = locale;
> +        this.canWriteCompressed = true;
>      }
>  }
>

Agreed, but if the size remains constant, it is not always a failure !

>
> Why not but it is a different scope ?
>>
>> I wrote the test focused on testing my patch to validate all my changes
>> and fix ASAP that very old bug (created in 2006) !
>>
>
> I understood, but to change the test and cover of existed/future plugins
> should not require a big effort. It does not mean that you need to fix some
> bugs(if any then create a new CR) in other plugins.
> See for example this bug JDK-8144245 which was found in a new plugin just
> because the test cover all of them. But this is up2you.
>

I tried generalizing it and moved it into shared/ImageWriterCompressionTest.

However I disabled bmp/gif as the file compression does not work but also
for JPG !!!

It seems jpg fails with the native error (on jdk9/client) but it works on
my jdk8_60:
Caused by: javax.imageio.IIOException: Invalid argument to native writeImage

Look at the IGNORE_FILE_SUFFIXES to re-enable JPEGImageWriter test if you
want.


To concluse: only PNG and the new TIFF pass (only LZW compression type is
tested).

Regards,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151211/c3e9bfcb/attachment.html>

From jayathirth.d.v at oracle.com  Fri Dec 11 06:14:59 2015
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Thu, 10 Dec 2015 22:14:59 -0800 (PST)
Subject: [OpenJDK 2D-Dev] [9] RFR: Test
 closed/javax/print/attribute/Services_getDocFl.java fails with
 NullpointerException (8040139)
In-Reply-To: <8937fb21-a1d2-41c2-849f-f9adb8241118@default>
References: <565EC976.5060104@oracle.com> <56691FEC.7070606@oracle.com>
	<56693367.1090807@oracle.com>
	<8937fb21-a1d2-41c2-849f-f9adb8241118@default>
Message-ID: <9e6fa0e6-a9f4-4b07-b51a-076ac3bf1063@default>

Since PrintServiceLookup.looupPrintServices is returning a printer service even when IPP printer is not accessible. Attributes we want get for the related print service should not be null(like print data formats/DocFlavors). Spec also mentions the same as pointed by Prasanta(returns at least one Doc Flavor).

?

By doing this we will avoid NPE. Also having user to select another printer from dialog(if selected printer is not available) is better than throwing NPE. Present changes are fine.

?

Thanks,

Jay

?

From: Jayathirth D V 
Sent: Thursday, December 10, 2015 5:10 PM
To: Prasanta Sadhukhan
Cc: 2d-dev at openjdk.java.net; Rajeev Chamyal; Philip Race; Sergey Bylokhov
Subject: RE: [OpenJDK 2D-Dev] [9] RFR: Test closed/javax/print/attribute/Services_getDocFl.java fails with NullpointerException (8040139)

?

Fix looks good to me.

?

From: prasanta sadhukhan 
Sent: Thursday, December 10, 2015 1:40 PM
To: Philip Race; Sergey Bylokhov
Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; Rajeev Chamyal
Subject: Re: [OpenJDK 2D-Dev] [9] RFR: Test closed/javax/print/attribute/Services_getDocFl.java fails with NullpointerException (8040139)

?

Thanks Phil for your approval.
I have opened up the closed test also. Here's the updated webrev:
http://cr.openjdk.java.net/~jdv/prasanta/8040139/webrev.01/

Sergey, would be able to +1 this?

Also, in addition to what Phil mentioned that it is expensive to enumerate for available printers in the network, we simply go for this fix to return an array with one entry in DocFlavor 
if the printer(s) already registered/added are not available and when user goes to print through the dialog, they would see the printer is "stopped" or "unable to connect" instead of a NPE.

Regards
Prasanta

On 12/10/2015 12:17 PM, Philip Race wrote:

I had to hunt for this since you did not include the bug number in the subject line.
The fix is fine although you really should explain to people why this approach is
taken rather than ignoring the printer. i.e it is prohibitively expensive to use
"lpstat -p" when simply enumerating available printers.

And I think the closed test can be opened. I don't see any problem with it and
it was developed internally.

-phil.


On 12/2/15, 2:35 AM, prasanta sadhukhan wrote: 

Hi All,

Please review a fix for jdk9 
Bug: https://bugs.openjdk.java.net/browse/JDK-8040139
webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/prasanta/8040139/webrev.00/"http://cr.openjdk.java.net/~jdv/prasanta/8040139/webrev.00/

It seems if a IPP printer is not accessible, PrintServiceLookup.lookupPrintServices will return the printer service but PrintService.getSupportedDocFlavors() will return null
since for the printer there is no way to answer the questions as to what it supports and if after that someone tries to access flavors.length it will cause NPE.
However, as per spec
https://docs.oracle.com/javase/8/docs/api/index.html?javax/print/PrintService.html
it clearly says, ??? 

Returns:

Array of supported doc flavors, should have at least one element.


so returning null is a violation of spec. 
I have added a fix to return DocService.SERVICE_FORMATTED flavor for such case.

Could not add a reg testcase as it will need an inaccessible printer.

Regards
Prasanta

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151210/f265bf5a/attachment.html>

From alexandr.scherbatiy at oracle.com  Fri Dec 11 20:09:12 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Sat, 12 Dec 2015 00:09:12 +0400
Subject: [OpenJDK 2D-Dev] Review request for 8069348
 SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D
In-Reply-To: <5658DC90.2010801@oracle.com>
References: <564F08B6.7010009@oracle.com> <564F3E8C.3040400@oracle.com>
	<564F4360.3070609@oracle.com> <5654610C.2090302@oracle.com>
	<5654D6F0.3090702@oracle.com> <56582B0E.20405@oracle.com>
	<5658DC90.2010801@oracle.com>
Message-ID: <566B2D68.10201@oracle.com>


Hello,

Could you review the updated fix:
   http://cr.openjdk.java.net/~alexsch/8069348/webrev.03

On 28/11/15 02:43, Jim Graham wrote:
> Hi Alexandr,
>
> On 11/27/15 2:06 AM, Alexander Scherbatiy wrote:
>>> OSXOffscreenSD.java (and all *SD.java), line 481 - should we just make
>>> this part of the SD.copyArea contract, that the coordinates are in
>>> device space and the SD method should not concern itself with the SG2D
>>> transform?
>>      I updated the SurfaceData.copyArea() x,y,width, and height
>> description.
>
> And yet most of the implementations still check the transformState. 
> Why do they do that if they are no longer concerned with transforming 
> the inputs?
   Updated.

   XRSurfaceData didn't handled translate scale transform state. I 
removed it and checked that on Linux scaled internal frames are properly 
moved and scroll works correctly.
   GDIWindowSurfaceData handles only translate state. For scale state 
support it is necessary also to scale destination coordinates. It is 
also requires some additional testing. I left it unchanged.
>
>>> CopyAreaTest.java, line 61 - rounding is not the same operation that
>>> SG2D uses, but it works anyway?
>
> The rounding still isn't the same as SG2D.  Floor() != ceil(v - 0.5).
>
> On second thought, it's probably best not to worry about the exact 
> rounding in the test case, but just test 1 pixel inset from the 
> coordinates that are needed.  In other words, check:
>
> scale(X + (N+1) * DX) + 1
> scale(Y + (N+1) * DY) + 1,
> scale(W) - 2
> scale(H) - 2
>
> and go back to just rounding...
    Updated.
>
>>> CopyAreaTest.java, lines 143,144 - why subtract 2DX and 2DY here? Ah,
>>> this may mask the error in line 94 above...?
>
> I notice that it used to check the rectangle at X+(N+1)*DX, 
> Y+(N+1)*DY, but now it only checks X+N*DX,Y+N*DY. Why not continue to 
> check the N+1 copy? That should be the location of the destination of 
> the last copy, right?
   I believe my initial assumption was incorrect.
   For example, let's take N = 1. The loops below has only one iteration:
     -----------
         for (int i = 0; i < N; i++) {
             g.copyArea(X + i * DX, Y + i * DY, W, H, DX, DY);
         }
     -----------

  Which is just g.copyArea(X, Y, W, H, DX, DY). So the destination 
rectangle is (X+DX, Y+DY, W, H)
  which corresponds to the N = 1.

  I also updated the test to check different scaleX and scaleY.

  Thanks,
  Alexandr.
>
>             ...jim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151212/a4ddbc09/attachment.html>

From volker.simonis at gmail.com  Fri Dec 11 10:47:43 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 11 Dec 2015 11:47:43 +0100
Subject: [OpenJDK 2D-Dev] RFR(S): 8145077: AIX: fix harfbuzz support
In-Reply-To: <5669CBAF.2010108@oracle.com>
References: <CA+3eh11B-RN03Hxa7NnicVVteXeh_=1byg9cF7Y8amemjg+9zw@mail.gmail.com>
	<CA+3eh11E3W=aPLZqcMj3=q54qtU9EgRT7WFveKbpCGOO5RmUCg@mail.gmail.com>
	<5669CBAF.2010108@oracle.com>
Message-ID: <CA+3eh13_6rtHkEUD4bLJ8GYw7VNibUST2ZVrPscseUOCM-A-GQ@mail.gmail.com>

Hi Phil,

thanks for the review!

Maybe I was unclear, but Behdad already integrated the exact patch upstream:

https://github.com/behdad/harfbuzz/commit/70b33edae7c8b9c031b83c95f00cb383789f1041
https://github.com/behdad/harfbuzz/commit/49e72634af74a9fbad01f42f48e104218413acc0

I'm not aware of any AIX specific label. We only have AIX as selection
in the OS section.

Regards,
Volker


On Thu, Dec 10, 2015 at 7:59 PM, Phil Race <philip.race at oracle.com> wrote:
>
> Should the compiler check go upstream too ?
> It is likely to get lost if it does not.
> Otherwise looks good. I've added noreg-other to the bug.
> Is there an "aix" label in use ?
>
> -phil.
>
>
> On 12/10/2015 09:38 AM, Volker Simonis wrote:
>>
>> Hi,
>>
>> here's a slightly updated version of my webrev which is now identical
>> to the version which has just been checked-in into the HarfBuzz
>> upstream repository (thanks to Behdad):
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8145077.v1
>>
>> Except some whitespace changes, the only real difference is that the
>> AIX atomic intrinsics are now additionally guarded by a compiler check
>> which ensures that they only get compiled with IBM's xlC compiler.
>>
>> Regards,
>> Volker
>>
>>
>> On Thu, Dec 10, 2015 at 2:13 PM, Volker Simonis
>> <volker.simonis at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> could somebody please review this AIX-only fix which adds the harfbuzz
>>> atomic primitives for AIX:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8145077/
>>> https://bugs.openjdk.java.net/browse/JDK-8145077
>>>
>>> I plan to also submit this patch upstream to the harfbuzz project to
>>> minimize the diffs between the upstream and the OpenJDK version.
>>>
>>> Notice that although this is a client patch I plan to push this
>>> directly to jdk9-dev because it fixes a build failure and I don't want
>>> to wait for the next round-trip trough jdk9-client.
>>>
>>> Thank you and best regards,
>>> Volker
>
>


From Sergey.Bylokhov at oracle.com  Fri Dec 11 12:02:34 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 11 Dec 2015 15:02:34 +0300
Subject: [OpenJDK 2D-Dev] RFR 6488522: PNG writer should permit setting
 compression level and iDAT chunk maximum size
In-Reply-To: <CAKjRUT71nwgQKLE0wVOw=7BTbjG2PLZzxwEY7UWuogR_nemx1w@mail.gmail.com>
References: <CAKjRUT4T7L8cK=SP0QM1LK-azLNexA0RNoq2FEFSdbSFetYr6g@mail.gmail.com>
	<56682A5E.6080904@oracle.com>
	<CAKjRUT5fu6fj1ugZ3Yf+C_RzNxRxqVyTb5my2GW5v=jr+n1+dA@mail.gmail.com>
	<566973A2.3000300@oracle.com>
	<CAKjRUT71nwgQKLE0wVOw=7BTbjG2PLZzxwEY7UWuogR_nemx1w@mail.gmail.com>
Message-ID: <566ABB5A.2070704@oracle.com>

Only one thing remain which I would like to clarify.

In the PNGImageWriter the new field deflaterLevel was added(it can be 
private?). This field is initialized by default to 
DEFAULT_COMPRESSION_LEVEL and updated according to the current params. 
Is it possible a situation if two images will use the same writer. 
During the write of the first image deflaterLevel will be changed via 
params. But in the write of the second image the params will be reset to 
null -> the deflaterLevel was not changed. It seems that in this case 
for the second image non-default level will be used?


On 11/12/15 02:45, Laurent Bourg?s wrote:
> Hi Sergey,
>
> Here is the updated webrev:
> http://cr.openjdk.java.net/~lbourges/png/PNGWriter-6488522.1/
>
>     A few notes:
>       - Should PNGImageWriteParam.unsetCompression resets the
>     compressionType to compressionTypes[0]?
>
>
> Fixed.
>
>       - Is it necessary to copy the checks in PNGImageWriteParam from
>     the parent? We can just call super() and expect that the parent
>     class validate current state.
>
>
> Agreed: I simply call super.getCompressionQualityXXX() before returning
> the appropriate value.
>
>
>         Yes, I could check that every png file is not zero-length or
>         that better
>         compression gives smaller file size !
>
>
>     It would be good, because right now it check not all changes in the fix.
>
>
> Fixed: I now check that better compression gives smaller file (but it
> may be not always the case as some algorithms use several passes or an
> adaptive strategy ...)
>
>         However, my changes rely on the public Deflater API that supports
>         compression levels between 0 to 9.
>
>         I suppose that this Deflater class is already covered by its own
>         tests
>         so I would prefer leaving the test as it is (no verification):
>         if the
>         Deflater raises any RuntimeException, then the
>         PNGWriterCompressionTest
>         will fail.
>
>
>     But this test is passed even for such fix:
>
>     ---
>     a/src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java
>     Thu Dec 10 14:21:44 2015 +0300
>     +++
>     b/src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java
>     Thu Dec 10 15:15:41 2015 +0300
>     @@ -280,6 +280,7 @@
>               super();
>               this.canWriteProgressive = true;
>               this.locale = locale;
>     +        this.canWriteCompressed = true;
>           }
>       }
>
>
> Agreed, but if the size remains constant, it is not always a failure !
>
>
>         Why not but it is a different scope ?
>
>         I wrote the test focused on testing my patch to validate all my
>         changes
>         and fix ASAP that very old bug (created in 2006) !
>
>
>     I understood, but to change the test and cover of existed/future
>     plugins should not require a big effort. It does not mean that you
>     need to fix some bugs(if any then create a new CR) in other plugins.
>     See for example this bug JDK-8144245 which was found in a new plugin
>     just because the test cover all of them. But this is up2you.
>
>
> I tried generalizing it and moved it into shared/ImageWriterCompressionTest.
>
> However I disabled bmp/gif as the file compression does not work but
> also for JPG !!!
>
> It seems jpg fails with the native error (on jdk9/client) but it works
> on my jdk8_60:
> Caused by: javax.imageio.IIOException: Invalid argument to native writeImage
>
> Look at the IGNORE_FILE_SUFFIXES to re-enable JPEGImageWriter test if
> you want.
>
>
> To concluse: only PNG and the new TIFF pass (only LZW compression type
> is tested).
>
> Regards,
> Laurent


-- 
Best regards, Sergey.


From bourges.laurent at gmail.com  Fri Dec 11 14:38:59 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 11 Dec 2015 15:38:59 +0100
Subject: [OpenJDK 2D-Dev] RFR 6488522: PNG writer should permit setting
 compression level and iDAT chunk maximum size
In-Reply-To: <566ABB5A.2070704@oracle.com>
References: <CAKjRUT4T7L8cK=SP0QM1LK-azLNexA0RNoq2FEFSdbSFetYr6g@mail.gmail.com>
	<56682A5E.6080904@oracle.com>
	<CAKjRUT5fu6fj1ugZ3Yf+C_RzNxRxqVyTb5my2GW5v=jr+n1+dA@mail.gmail.com>
	<566973A2.3000300@oracle.com>
	<CAKjRUT71nwgQKLE0wVOw=7BTbjG2PLZzxwEY7UWuogR_nemx1w@mail.gmail.com>
	<566ABB5A.2070704@oracle.com>
Message-ID: <CAKjRUT5_dfCGa1Bz9-VYhA2sadoj6L+pejnVTcLGMS84=SNX6A@mail.gmail.com>

Sergey,

2015-12-11 13:02 GMT+01:00 Sergey Bylokhov <Sergey.Bylokhov at oracle.com>:

> Only one thing remain which I would like to clarify.
>
> In the PNGImageWriter the new field deflaterLevel was added(it can be
> private?). This field is initialized by default to
> DEFAULT_COMPRESSION_LEVEL and updated according to the current params. Is
> it possible a situation if two images will use the same writer. During the
> write of the first image deflaterLevel will be changed via params. But in
> the write of the second image the params will be reset to null -> the
> deflaterLevel was not changed. It seems that in this case for the second
> image non-default level will be used?


Good catch !

I fixed that issue by resetting the compression level to the default value
before using or not params.

Here is an updated webrev:
http://cr.openjdk.java.net/~lbourges/png/PNGWriter-6488522.2/

The jtreg ImageCompressionTest still passes (I did not update it).

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151211/39fd6482/attachment.html>

From Sergey.Bylokhov at oracle.com  Fri Dec 11 15:57:12 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 11 Dec 2015 18:57:12 +0300
Subject: [OpenJDK 2D-Dev] RFR 6488522: PNG writer should permit setting
 compression level and iDAT chunk maximum size
In-Reply-To: <CAKjRUT5_dfCGa1Bz9-VYhA2sadoj6L+pejnVTcLGMS84=SNX6A@mail.gmail.com>
References: <CAKjRUT4T7L8cK=SP0QM1LK-azLNexA0RNoq2FEFSdbSFetYr6g@mail.gmail.com>
	<56682A5E.6080904@oracle.com>
	<CAKjRUT5fu6fj1ugZ3Yf+C_RzNxRxqVyTb5my2GW5v=jr+n1+dA@mail.gmail.com>
	<566973A2.3000300@oracle.com>
	<CAKjRUT71nwgQKLE0wVOw=7BTbjG2PLZzxwEY7UWuogR_nemx1w@mail.gmail.com>
	<566ABB5A.2070704@oracle.com>
	<CAKjRUT5_dfCGa1Bz9-VYhA2sadoj6L+pejnVTcLGMS84=SNX6A@mail.gmail.com>
Message-ID: <566AF258.3050008@oracle.com>

On 11/12/15 17:38, Laurent Bourg?s wrote:
> I fixed that issue by resetting the compression level to the default
> value before using or not params.

Probably it can be made local to the write method, but this version 
looks fine too.

>
> Here is an updated webrev:
> http://cr.openjdk.java.net/~lbourges/png/PNGWriter-6488522.2/
>
> The jtreg ImageCompressionTest still passes (I did not update it).
>
> Cheers,
> Laurent


-- 
Best regards, Sergey.


From srl at icu-project.org  Fri Dec 11 16:51:57 2015
From: srl at icu-project.org (Steven R. Loomis)
Date: Fri, 11 Dec 2015 08:51:57 -0800
Subject: [OpenJDK 2D-Dev] Question regarding the integration of harfbuzz
	(JEP 258)
In-Reply-To: <CAOY=jUTkf3Y4jjqsSbx8ErgiBNhRQvjPSVETbOVqUa9ABFshAg@mail.gmail.com>
References: <56685EA9.8020704@oracle.com> <56685F3D.9000607@oracle.com>
	<D6F95352-C873-4C54-AC90-08A4E3BBB305@icu-project.org>
	<CA+3eh12V-G2L4uc5G=Yj75tG_KYUDDiud6zpYxwSHJ0VjC1QPA@mail.gmail.com>
	<CAOY=jUQKRUSdukaRHQ60r_+hVw6=z=nr1sRjB+OwkXx49nMO2A@mail.gmail.com>
	<CAOY=jUTkf3Y4jjqsSbx8ErgiBNhRQvjPSVETbOVqUa9ABFshAg@mail.gmail.com>
Message-ID: <205300DA-9921-4AAA-B91D-F2CA8FDE3AC0@icu-project.org>

AIX can use pthread, yes. 

I'll take a look at the patch. Thanks Volker for your reply.   

Enviado desde nuestro iPhone.

> El dic 10, 2015, a las 6:55 AM, Behdad Esfahbod <behdad at google.com> escribi?:
> 
> Slightly shuffled patch was committed upstream:
> https://github.com/behdad/harfbuzz/commit/70b33edae7c8b9c031b83c95f00cb383789f1041
> 
> Thanks,
> behdad
> 
> 
>> On Thu, Dec 10, 2015 at 2:36 PM, Behdad Esfahbod <behdad at google.com> wrote:
>> Hi Volker, Steven,
>> 
>> I'd happily take AIX atomic primitive patch for HarfBuzz.  Yes, github Pull-Requests are fine.  As you correctly identified, HarfBuzz uses atomic ops and mutexes to synchronize access to global data as well as reference-counting from multiple threads, even though it doesn't uses threads itself.
>> 
>> Does AIX use pthread for threading?  I can definitely add a threading stress-test to HarfBuzz.  I definitely should.  Filed here:
>> 
>>   https://github.com/behdad/harfbuzz/issues/195
>> 
>> Thanks,
>> behdad
>> 
>>> On Thu, Dec 10, 2015 at 2:27 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>> Hi Steven,
>>> 
>>> thanks for your response.
>>> 
>>>> On Thu, Dec 10, 2015 at 1:44 AM, Steven R. Loomis <srl at icu-project.org> wrote:
>>>> Volker,
>>>>  0. I?d like to see what the crashing stack frame is when NOT on harfbuzz, because there should be no change.
>>> 
>>> This was another problem. Please see my previous mail in this thread where I've described the cause in more detail.
>>>  
>>>>  1. Phil addressed this one
>>>> 
>>>>  2. I will take a look on AIX. I?ll see if I can build Harfbuzz itself on AIX at first.
>>> 
>>> I've fixed it now and just send around a request for review: http://mail.openjdk.java.net/pipermail/2d-dev/2015-December/006065.html
>>> 
>>> The mail contains a link to the bug and the patch which fixes it.
>>> 
>>> I also want to contribute this to harfbuzz. Is it OK to send a pull request to https://github.com/behdad/harfbuzz ?
>>> 
>>>>  3. Yes, I?ll work on putting some docs together for that test.  Actually, other tests such as the Font2DTest  would be a good test. Or, any text in a complex script such as Hindi.
>>> 
>>> That would be great. For now, the Font2DTest runs without a problem with harfbuzz on AIX (and linux/ppc64).
>>>  
>>>>  4. I?m not sure. A threaded stress test would be good.  Perhaps Harfbuzz-in-JDK could leverage the hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp you mentioned. 
>>>>  
>>>>  Behdad - file is here http://hg.openjdk.java.net/jdk9/client/hotspot/file/c8e212fb27d0/src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp  - any comments on this or other items? 
>>> 
>>> That sounds like a good idea but unfortunately the hotspot primitives are in a different repository (source-code wise) and in a different library (i.e. libjvm.so) which doesn't export them. So the best we can do for now would be to copy the missing parts over to the jdk repository (and that's actually what I've done now for the AIX version of the primitives).
>>> 
>>> Regards,
>>> Volker
>>>  
>>>> -s
>>>> 
>>>>> 
>>>>> -------- Original Message --------
>>>>> Subject:	Re: [OpenJDK 2D-Dev] Question regarding the integration of harfbuzz (JEP 258)
>>>>> Date:	Wed, 09 Dec 2015 09:02:33 -0800
>>>>> From:	Philip Race <philip.race at oracle.com>
>>>>> Organization:	Oracle Corporation
>>>>> To:	2d-dev at openjdk.java.net
>>>>> 
>>>>> 
>>>>> Hi Volker,
>>>>> 
>>>>> Running with ICU should stop harfbuzz use completely so if
>>>>> you are still seeing a crash, perhaps it is due to something else entirely.
>>>>> Especially since a "simple AWT program" should not load layout anyway.
>>>>> There was a fair amount of new and changed code pushed recently ...
>>>>> 
>>>>> Yes, we need to run harfbuzz in multiple concurrent threads in the JDK.
>>>>> A single threaded lock on harfbuzz would throttle text operations.
>>>>> I suppose it is possible that we do not strictly need it as we currently 
>>>>> create a
>>>>> new harfbuzz "instance" each time we go to invoke layout but that
>>>>> is something that at least theoretically could change.
>>>>> 
>>>>> The approach to synchronization is all from up-stream harfbuzz.
>>>>> The harfbuzz mailing list might be the place to discuss that.
>>>>> I'd expect it does work on AIX as a principal driver here is that
>>>>> the IBM sponsored ICU project has deprecated its layout engine
>>>>> and IBM/ICU are moving to harfbuzz so I'd be somewhat astonished
>>>>> if they haven't yet tried it on AIX. Did you try just getting a copy
>>>>> of the full hotspot library and running its configure on AIX to see if
>>>>> harfbuzz can work out which options it wants there ? Obviously
>>>>> I did not try that since I don't have AIX. Steven Loomis of IBM
>>>>> who submitted the JEP should be able to help with a lot of this.
>>>>> 
>>>>> -phil.
>>>>> 
>>>>> On 12/8/15, 10:50 AM, Volker Simonis wrote:
>>>>> > Hi,
>>>>> >
>>>>> > the integration of harfbuzz broke our AIX build because there's no
>>>>> > implementation available for the hb_atomic macros in
>>>>> > hb-atomic-private.hh. I've fixed that locally but still get a crash
>>>>> > when running a simple AWT program (even with
>>>>> > -Dsun.font.layoutengine=icu).
>>>>> >
>>>>> > I'm curretnly debugging the problem, but I have some general questions:
>>>>> >
>>>>> > 1. Do we really need the multi-threaded features of harfbuzz in OpenJDK?
>>>>> >
>>>>> > 2. Why does hurbuzz require these synchronization macros? From a first
>>>>> > glance it doesn't seem to use multiple threads by itself. Does it have
>>>>> > some global data structures which it needs to protect if harfbuzz is
>>>>> > called from various threads?
>>>>> >
>>>>> > 3. Is there a way to test the hurfbuzz engine on a new platform? I saw
>>>>> > the new test TestLayoutVsICU.java but it is marked as "manual" and it
>>>>> > seems to require external fonts (at least some of which seem to be
>>>>> > freely available). Could you please provide at least a minimal
>>>>> > description on how this test can be run?
>>>>> >
>>>>> > 4. Is there a way to test that the implementation of the hb_atomic
>>>>> > macros in hb-atomic-private.hh is correct (i.e. a way to stress
>>>>> > harfbuzz from multiple threads)? I think this is important as I
>>>>> > couldn't find a good description of the requirements for the atomic
>>>>> > macros and on weak memory model architectures we should really get
>>>>> > this right. For example there's no description of which fences are
>>>>> > required around the various atomic operations. Getting this right
>>>>> > across all platforms in the HotSpot (see
>>>>> > hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp) is already hard
>>>>> > enough so I'm a little concerned that we are now introducing similar
>>>>> > primitives in the class library.
>>>>> >
>>>>> > Thank you and best regards,
>>>>> > Volker
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151211/6e76706b/attachment.html>

From srl at icu-project.org  Fri Dec 11 16:53:04 2015
From: srl at icu-project.org (Steven R. Loomis)
Date: Fri, 11 Dec 2015 08:53:04 -0800
Subject: [OpenJDK 2D-Dev] Question regarding the integration of harfbuzz
	(JEP 258)
In-Reply-To: <CA+3eh109hpcmg816+9K0gffzjxpa3NRazW=ZSJFko7a3v0Tu+A@mail.gmail.com>
References: <56685EA9.8020704@oracle.com> <56685F3D.9000607@oracle.com>
	<D6F95352-C873-4C54-AC90-08A4E3BBB305@icu-project.org>
	<CA+3eh12V-G2L4uc5G=Yj75tG_KYUDDiud6zpYxwSHJ0VjC1QPA@mail.gmail.com>
	<CAOY=jUQKRUSdukaRHQ60r_+hVw6=z=nr1sRjB+OwkXx49nMO2A@mail.gmail.com>
	<CAOY=jUTkf3Y4jjqsSbx8ErgiBNhRQvjPSVETbOVqUa9ABFshAg@mail.gmail.com>
	<CA+3eh109hpcmg816+9K0gffzjxpa3NRazW=ZSJFko7a3v0Tu+A@mail.gmail.com>
Message-ID: <A5A116F2-4277-44E7-B997-3CB0CCF2B342@icu-project.org>

Yes I had the same trouble compiling harfbuzz. I'm close though. 

Enviado desde nuestro iPhone.

> El dic 10, 2015, a las 8:12 AM, Volker Simonis <volker.simonis at gmail.com> escribi?:
> 
> Behdad,
> 
> you're really great!!!
> 
> I've forked HarfBuzz today because I wanted to submit a pull request with the change. Unfortunately I was not able to build on AIX until now (plenty of nasty problems will all kind of missing or too old tools :(
> 
> And now I see that you've already pushed the change! Thanks a lot. I'd only like to suggest the following minor enhancement to my initial change. It restricts the change to the case where HarfBuzz will be compiled with IBM's xlC compiler because it uses xlC compiler intrinsics. I know there are people out there who package open source software for AIX but they usually compile the whole toolchain with GCC. This minor addition will protect them from running into compile errors if they should ever try to compile HarfBuzz with GCC on AIX.
> 
> It would be great if you could add that as well to the upstream version.
> 
> I will then update my OpenJDK patch to contain exactly your "shuffeled" upstream version so we don't get any problems when merging from upstream in the future.
> 
> Thanks a lot once again,
> Volker
> 
> 
> diff -r fd95f33023e9 src/java.desktop/share/native/libfontmanager/harfbuzz/hb-atomic-private.hh
> --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-atomic-private.hh        Thu Dec 10 12:13:22 2015 +0100
> +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-atomic-private.hh        Thu Dec 10 16:55:58 2015 +0100
> @@ -119,7 +119,7 @@
>  #define hb_atomic_ptr_impl_cmpexch(P,O,N)       ( ({__machine_rw_barrier ();}), atomic_cas_ptr ((void **) (P), (void *) (O), (void *) (N)) == (void *) (O) ? true : false)
>  
>  
> -#elif !defined(HB_NO_MT) && defined(_AIX)
> +#elif !defined(HB_NO_MT) && defined(_AIX) && defined(__IBMCPP__)
>  
>  #include <builtins.h>
>  
> 
> 
>> On Thu, Dec 10, 2015 at 3:55 PM, Behdad Esfahbod <behdad at google.com> wrote:
>> Slightly shuffled patch was committed upstream:
>> https://github.com/behdad/harfbuzz/commit/70b33edae7c8b9c031b83c95f00cb383789f1041
>> 
>> Thanks,
>> behdad
>> 
>> 
>>> On Thu, Dec 10, 2015 at 2:36 PM, Behdad Esfahbod <behdad at google.com> wrote:
>>> Hi Volker, Steven,
>>> 
>>> I'd happily take AIX atomic primitive patch for HarfBuzz.  Yes, github Pull-Requests are fine.  As you correctly identified, HarfBuzz uses atomic ops and mutexes to synchronize access to global data as well as reference-counting from multiple threads, even though it doesn't uses threads itself.
>>> 
>>> Does AIX use pthread for threading?  I can definitely add a threading stress-test to HarfBuzz.  I definitely should.  Filed here:
>>> 
>>>   https://github.com/behdad/harfbuzz/issues/195
>>> 
>>> Thanks,
>>> behdad
>>> 
>>>> On Thu, Dec 10, 2015 at 2:27 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>>> Hi Steven,
>>>> 
>>>> thanks for your response.
>>>> 
>>>>> On Thu, Dec 10, 2015 at 1:44 AM, Steven R. Loomis <srl at icu-project.org> wrote:
>>>>> Volker,
>>>>>  0. I?d like to see what the crashing stack frame is when NOT on harfbuzz, because there should be no change.
>>>> 
>>>> This was another problem. Please see my previous mail in this thread where I've described the cause in more detail.
>>>>  
>>>>>  1. Phil addressed this one
>>>>> 
>>>>>  2. I will take a look on AIX. I?ll see if I can build Harfbuzz itself on AIX at first.
>>>> 
>>>> I've fixed it now and just send around a request for review: http://mail.openjdk.java.net/pipermail/2d-dev/2015-December/006065.html
>>>> 
>>>> The mail contains a link to the bug and the patch which fixes it.
>>>> 
>>>> I also want to contribute this to harfbuzz. Is it OK to send a pull request to https://github.com/behdad/harfbuzz ?
>>>> 
>>>>>  3. Yes, I?ll work on putting some docs together for that test.  Actually, other tests such as the Font2DTest  would be a good test. Or, any text in a complex script such as Hindi.
>>>> 
>>>> That would be great. For now, the Font2DTest runs without a problem with harfbuzz on AIX (and linux/ppc64).
>>>>  
>>>>>  4. I?m not sure. A threaded stress test would be good.  Perhaps Harfbuzz-in-JDK could leverage the hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp you mentioned. 
>>>>>  
>>>>>  Behdad - file is here http://hg.openjdk.java.net/jdk9/client/hotspot/file/c8e212fb27d0/src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp  - any comments on this or other items? 
>>>> 
>>>> That sounds like a good idea but unfortunately the hotspot primitives are in a different repository (source-code wise) and in a different library (i.e. libjvm.so) which doesn't export them. So the best we can do for now would be to copy the missing parts over to the jdk repository (and that's actually what I've done now for the AIX version of the primitives).
>>>> 
>>>> Regards,
>>>> Volker
>>>>  
>>>>> -s
>>>>> 
>>>>>> 
>>>>>> -------- Original Message --------
>>>>>> Subject:	Re: [OpenJDK 2D-Dev] Question regarding the integration of harfbuzz (JEP 258)
>>>>>> Date:	Wed, 09 Dec 2015 09:02:33 -0800
>>>>>> From:	Philip Race <philip.race at oracle.com>
>>>>>> Organization:	Oracle Corporation
>>>>>> To:	2d-dev at openjdk.java.net
>>>>>> 
>>>>>> 
>>>>>> Hi Volker,
>>>>>> 
>>>>>> Running with ICU should stop harfbuzz use completely so if
>>>>>> you are still seeing a crash, perhaps it is due to something else entirely.
>>>>>> Especially since a "simple AWT program" should not load layout anyway.
>>>>>> There was a fair amount of new and changed code pushed recently ...
>>>>>> 
>>>>>> Yes, we need to run harfbuzz in multiple concurrent threads in the JDK.
>>>>>> A single threaded lock on harfbuzz would throttle text operations.
>>>>>> I suppose it is possible that we do not strictly need it as we currently 
>>>>>> create a
>>>>>> new harfbuzz "instance" each time we go to invoke layout but that
>>>>>> is something that at least theoretically could change.
>>>>>> 
>>>>>> The approach to synchronization is all from up-stream harfbuzz.
>>>>>> The harfbuzz mailing list might be the place to discuss that.
>>>>>> I'd expect it does work on AIX as a principal driver here is that
>>>>>> the IBM sponsored ICU project has deprecated its layout engine
>>>>>> and IBM/ICU are moving to harfbuzz so I'd be somewhat astonished
>>>>>> if they haven't yet tried it on AIX. Did you try just getting a copy
>>>>>> of the full hotspot library and running its configure on AIX to see if
>>>>>> harfbuzz can work out which options it wants there ? Obviously
>>>>>> I did not try that since I don't have AIX. Steven Loomis of IBM
>>>>>> who submitted the JEP should be able to help with a lot of this.
>>>>>> 
>>>>>> -phil.
>>>>>> 
>>>>>> On 12/8/15, 10:50 AM, Volker Simonis wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > the integration of harfbuzz broke our AIX build because there's no
>>>>>> > implementation available for the hb_atomic macros in
>>>>>> > hb-atomic-private.hh. I've fixed that locally but still get a crash
>>>>>> > when running a simple AWT program (even with
>>>>>> > -Dsun.font.layoutengine=icu).
>>>>>> >
>>>>>> > I'm curretnly debugging the problem, but I have some general questions:
>>>>>> >
>>>>>> > 1. Do we really need the multi-threaded features of harfbuzz in OpenJDK?
>>>>>> >
>>>>>> > 2. Why does hurbuzz require these synchronization macros? From a first
>>>>>> > glance it doesn't seem to use multiple threads by itself. Does it have
>>>>>> > some global data structures which it needs to protect if harfbuzz is
>>>>>> > called from various threads?
>>>>>> >
>>>>>> > 3. Is there a way to test the hurfbuzz engine on a new platform? I saw
>>>>>> > the new test TestLayoutVsICU.java but it is marked as "manual" and it
>>>>>> > seems to require external fonts (at least some of which seem to be
>>>>>> > freely available). Could you please provide at least a minimal
>>>>>> > description on how this test can be run?
>>>>>> >
>>>>>> > 4. Is there a way to test that the implementation of the hb_atomic
>>>>>> > macros in hb-atomic-private.hh is correct (i.e. a way to stress
>>>>>> > harfbuzz from multiple threads)? I think this is important as I
>>>>>> > couldn't find a good description of the requirements for the atomic
>>>>>> > macros and on weak memory model architectures we should really get
>>>>>> > this right. For example there's no description of which fences are
>>>>>> > required around the various atomic operations. Getting this right
>>>>>> > across all platforms in the HotSpot (see
>>>>>> > hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp) is already hard
>>>>>> > enough so I'm a little concerned that we are now introducing similar
>>>>>> > primitives in the class library.
>>>>>> >
>>>>>> > Thank you and best regards,
>>>>>> > Volker
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151211/01018bc7/attachment.html>

From volker.simonis at gmail.com  Fri Dec 11 16:59:13 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 11 Dec 2015 17:59:13 +0100
Subject: [OpenJDK 2D-Dev] Question regarding the integration of harfbuzz
 (JEP 258)
In-Reply-To: <A5A116F2-4277-44E7-B997-3CB0CCF2B342@icu-project.org>
References: <56685EA9.8020704@oracle.com> <56685F3D.9000607@oracle.com>
	<D6F95352-C873-4C54-AC90-08A4E3BBB305@icu-project.org>
	<CA+3eh12V-G2L4uc5G=Yj75tG_KYUDDiud6zpYxwSHJ0VjC1QPA@mail.gmail.com>
	<CAOY=jUQKRUSdukaRHQ60r_+hVw6=z=nr1sRjB+OwkXx49nMO2A@mail.gmail.com>
	<CAOY=jUTkf3Y4jjqsSbx8ErgiBNhRQvjPSVETbOVqUa9ABFshAg@mail.gmail.com>
	<CA+3eh109hpcmg816+9K0gffzjxpa3NRazW=ZSJFko7a3v0Tu+A@mail.gmail.com>
	<A5A116F2-4277-44E7-B997-3CB0CCF2B342@icu-project.org>
Message-ID: <CA+3eh12+BHTXcYJQ-vqVPZJXeyepV1DQ_+O7sUGbcMXajjgqyg@mail.gmail.com>

I hope you're using xlC to compile harfbuzz on AIX. Using the GNU tool
chain wouldn't be fair :)
We're also using xlC for compiling the OpenJDK so GCC is no option for us.

Please let me know if you've succeeded and what you had to do. This would
be especially interesting if there will exist some multithreading tests one
day so I could run them and verify if the atomic primitives are fine.

Regards,
Volker


On Fri, Dec 11, 2015 at 5:53 PM, Steven R. Loomis <srl at icu-project.org>
wrote:

> Yes I had the same trouble compiling harfbuzz. I'm close though.
>
> Enviado desde nuestro iPhone.
>
> El dic 10, 2015, a las 8:12 AM, Volker Simonis <volker.simonis at gmail.com>
> escribi?:
>
> Behdad,
>
> you're really great!!!
>
> I've forked HarfBuzz today because I wanted to submit a pull request with
> the change. Unfortunately I was not able to build on AIX until now (plenty
> of nasty problems will all kind of missing or too old tools :(
>
> And now I see that you've already pushed the change! Thanks a lot. I'd
> only like to suggest the following minor enhancement to my initial change.
> It restricts the change to the case where HarfBuzz will be compiled with
> IBM's xlC compiler because it uses xlC compiler intrinsics. I know there
> are people out there who package open source software for AIX but they
> usually compile the whole toolchain with GCC. This minor addition will
> protect them from running into compile errors if they should ever try to
> compile HarfBuzz with GCC on AIX.
>
> It would be great if you could add that as well to the upstream version.
>
> I will then update my OpenJDK patch to contain exactly your "shuffeled"
> upstream version so we don't get any problems when merging from upstream in
> the future.
>
> Thanks a lot once again,
> Volker
>
>
> diff -r fd95f33023e9
> src/java.desktop/share/native/libfontmanager/harfbuzz/hb-atomic-private.hh
> ---
> a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-atomic-private.hh
> Thu Dec 10 12:13:22 2015 +0100
> +++
> b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-atomic-private.hh
> Thu Dec 10 16:55:58 2015 +0100
> @@ -119,7 +119,7 @@
>  #define hb_atomic_ptr_impl_cmpexch(P,O,N)       ( ({__machine_rw_barrier
> ();}), atomic_cas_ptr ((void **) (P), (void *) (O), (void *) (N)) == (void
> *) (O) ? true : false)
>
>
> -#elif !defined(HB_NO_MT) && defined(_AIX)
> +#elif !defined(HB_NO_MT) && defined(_AIX) && defined(__IBMCPP__)
>
>  #include <builtins.h>
>
>
>
> On Thu, Dec 10, 2015 at 3:55 PM, Behdad Esfahbod <behdad at google.com>
> wrote:
>
>> Slightly shuffled patch was committed upstream:
>>
>> https://github.com/behdad/harfbuzz/commit/70b33edae7c8b9c031b83c95f00cb383789f1041
>>
>> Thanks,
>> behdad
>>
>>
>> On Thu, Dec 10, 2015 at 2:36 PM, Behdad Esfahbod <behdad at google.com>
>> wrote:
>>
>>> Hi Volker, Steven,
>>>
>>> I'd happily take AIX atomic primitive patch for HarfBuzz.  Yes, github
>>> Pull-Requests are fine.  As you correctly identified, HarfBuzz uses atomic
>>> ops and mutexes to synchronize access to global data as well as
>>> reference-counting from multiple threads, even though it doesn't uses
>>> threads itself.
>>>
>>> Does AIX use pthread for threading?  I can definitely add a threading
>>> stress-test to HarfBuzz.  I definitely should.  Filed here:
>>>
>>>   https://github.com/behdad/harfbuzz/issues/195
>>>
>>> Thanks,
>>> behdad
>>>
>>> On Thu, Dec 10, 2015 at 2:27 PM, Volker Simonis <
>>> volker.simonis at gmail.com> wrote:
>>>
>>>> Hi Steven,
>>>>
>>>> thanks for your response.
>>>>
>>>> On Thu, Dec 10, 2015 at 1:44 AM, Steven R. Loomis <srl at icu-project.org>
>>>> wrote:
>>>>
>>>>> Volker,
>>>>>  0. I?d like to see what the crashing stack frame is when NOT on
>>>>> harfbuzz, because there should be no change.
>>>>>
>>>>>
>>>> This was another problem. Please see my previous mail in this thread
>>>> where I've described the cause in more detail.
>>>>
>>>>
>>>>>  1. Phil addressed this one
>>>>>
>>>>>  2. I will take a look on AIX. I?ll see if I can build Harfbuzz itself
>>>>> on AIX at first.
>>>>>
>>>>>
>>>> I've fixed it now and just send around a request for review:
>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2015-December/006065.html
>>>>
>>>> The mail contains a link to the bug and the patch which fixes it.
>>>>
>>>> I also want to contribute this to harfbuzz. Is it OK to send a pull
>>>> request to https://github.com/behdad/harfbuzz ?
>>>>
>>>>  3. Yes, I?ll work on putting some docs together for that test.
>>>>> Actually, other tests such as the Font2DTest  would be a good test. Or, any
>>>>> text in a complex script such as Hindi.
>>>>>
>>>>>
>>>> That would be great. For now, the Font2DTest runs without a problem
>>>> with harfbuzz on AIX (and linux/ppc64).
>>>>
>>>>
>>>>>  4. I?m not sure. A threaded stress test would be good.  Perhaps
>>>>> Harfbuzz-in-JDK could leverage the
>>>>> hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp you mentioned.
>>>>>
>>>>>  Behdad - file is here
>>>>> http://hg.openjdk.java.net/jdk9/client/hotspot/file/c8e212fb27d0/src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp
>>>>>  - any comments on this or other items?
>>>>>
>>>>>
>>>> That sounds like a good idea but unfortunately the hotspot primitives
>>>> are in a different repository (source-code wise) and in a different library
>>>> (i.e. libjvm.so) which doesn't export them. So the best we can do for now
>>>> would be to copy the missing parts over to the jdk repository (and that's
>>>> actually what I've done now for the AIX version of the primitives).
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>
>>>>> -s
>>>>>
>>>>>
>>>>> -------- Original Message -------- Subject: Re: [OpenJDK 2D-Dev]
>>>>> Question regarding the integration of harfbuzz (JEP 258) Date: Wed,
>>>>> 09 Dec 2015 09:02:33 -0800 From: Philip Race <philip.race at oracle.com>
>>>>> <philip.race at oracle.com> Organization: Oracle Corporation To:
>>>>> 2d-dev at openjdk.java.net
>>>>>
>>>>>
>>>>> Hi Volker,
>>>>>
>>>>> Running with ICU should stop harfbuzz use completely so if
>>>>> you are still seeing a crash, perhaps it is due to something else entirely.
>>>>> Especially since a "simple AWT program" should not load layout anyway.
>>>>> There was a fair amount of new and changed code pushed recently ...
>>>>>
>>>>> Yes, we need to run harfbuzz in multiple concurrent threads in the JDK.
>>>>> A single threaded lock on harfbuzz would throttle text operations.
>>>>> I suppose it is possible that we do not strictly need it as we currently
>>>>> create a
>>>>> new harfbuzz "instance" each time we go to invoke layout but that
>>>>> is something that at least theoretically could change.
>>>>>
>>>>> The approach to synchronization is all from up-stream harfbuzz.
>>>>> The harfbuzz mailing list might be the place to discuss that.
>>>>> I'd expect it does work on AIX as a principal driver here is that
>>>>> the IBM sponsored ICU project has deprecated its layout engine
>>>>> and IBM/ICU are moving to harfbuzz so I'd be somewhat astonished
>>>>> if they haven't yet tried it on AIX. Did you try just getting a copy
>>>>> of the full hotspot library and running its configure on AIX to see if
>>>>> harfbuzz can work out which options it wants there ? Obviously
>>>>> I did not try that since I don't have AIX. Steven Loomis of IBM
>>>>> who submitted the JEP should be able to help with a lot of this.
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 12/8/15, 10:50 AM, Volker Simonis wrote:
>>>>> > Hi,
>>>>> >
>>>>> > the integration of harfbuzz broke our AIX build because there's no
>>>>> > implementation available for the hb_atomic macros in
>>>>> > hb-atomic-private.hh. I've fixed that locally but still get a crash
>>>>> > when running a simple AWT program (even with
>>>>> > -Dsun.font.layoutengine=icu).
>>>>> >
>>>>> > I'm curretnly debugging the problem, but I have some general questions:
>>>>> >
>>>>> > 1. Do we really need the multi-threaded features of harfbuzz in OpenJDK?
>>>>> >
>>>>> > 2. Why does hurbuzz require these synchronization macros? From a first
>>>>> > glance it doesn't seem to use multiple threads by itself. Does it have
>>>>> > some global data structures which it needs to protect if harfbuzz is
>>>>> > called from various threads?
>>>>> >
>>>>> > 3. Is there a way to test the hurfbuzz engine on a new platform? I saw
>>>>> > the new test TestLayoutVsICU.java but it is marked as "manual" and it
>>>>> > seems to require external fonts (at least some of which seem to be
>>>>> > freely available). Could you please provide at least a minimal
>>>>> > description on how this test can be run?
>>>>> >
>>>>> > 4. Is there a way to test that the implementation of the hb_atomic
>>>>> > macros in hb-atomic-private.hh is correct (i.e. a way to stress
>>>>> > harfbuzz from multiple threads)? I think this is important as I
>>>>> > couldn't find a good description of the requirements for the atomic
>>>>> > macros and on weak memory model architectures we should really get
>>>>> > this right. For example there's no description of which fences are
>>>>> > required around the various atomic operations. Getting this right
>>>>> > across all platforms in the HotSpot (see
>>>>> > hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp) is already hard
>>>>> > enough so I'm a little concerned that we are now introducing similar
>>>>> > primitives in the class library.
>>>>> >
>>>>> > Thank you and best regards,
>>>>> > Volker
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151211/9e6b0a8e/attachment.html>

From bourges.laurent at gmail.com  Fri Dec 11 17:59:21 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 11 Dec 2015 18:59:21 +0100
Subject: [OpenJDK 2D-Dev] RFR 6488522: PNG writer should permit setting
 compression level and iDAT chunk maximum size
In-Reply-To: <566AF258.3050008@oracle.com>
References: <CAKjRUT4T7L8cK=SP0QM1LK-azLNexA0RNoq2FEFSdbSFetYr6g@mail.gmail.com>
	<56682A5E.6080904@oracle.com>
	<CAKjRUT5fu6fj1ugZ3Yf+C_RzNxRxqVyTb5my2GW5v=jr+n1+dA@mail.gmail.com>
	<566973A2.3000300@oracle.com>
	<CAKjRUT71nwgQKLE0wVOw=7BTbjG2PLZzxwEY7UWuogR_nemx1w@mail.gmail.com>
	<566ABB5A.2070704@oracle.com>
	<CAKjRUT5_dfCGa1Bz9-VYhA2sadoj6L+pejnVTcLGMS84=SNX6A@mail.gmail.com>
	<566AF258.3050008@oracle.com>
Message-ID: <CAKjRUT6b6oS7cdJwfCNEWByosnNFogbC2aZ=q-rhGHztqBDBVg@mail.gmail.com>

Sergey,
>> I fixed that issue by resetting the compression level to the default
>> value before using or not params.
>
>
> Probably it can be made local to the write method, but this version looks
fine too.

You're right. I will improve that, I did it too quickly.

Maybe I should also improve other DeflaterOutputStream usage: 1 per
keyword, see deflate (byte []), it seems roughly unoptimized...

Cheers,
Laurent

>
>
>>
>> Here is an updated webrev:
>> http://cr.openjdk.java.net/~lbourges/png/PNGWriter-6488522.2/
>>
>> The jtreg ImageCompressionTest still passes (I did not update it).
>>
>> Cheers,
>> Laurent
>
>
>
> --
> Best regards, Sergey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151211/52354969/attachment.html>

From brian.burkhalter at oracle.com  Fri Dec 11 22:45:28 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 11 Dec 2015 14:45:28 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8144997: "IIOException: Field data is past
	end-of-stream" when calling TIFFImageReader.read()
Message-ID: <2BFDAA11-750C-4C02-8151-A9755877D9D4@oracle.com>

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8144997
Patch:	http://cr.openjdk.java.net/~bpb/8144997/webrev.00/

Summary:

1. lines 478-481: If the IFD entry has an unknown data type, skip the entry.
2. line 528: if the offset to the field?s value is out of the stream, skip the IFD entry instead of throwing an exception.

Thanks,

Brian

From philip.race at oracle.com  Fri Dec 11 22:50:15 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 11 Dec 2015 14:50:15 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8144997: "IIOException: Field data is
 past end-of-stream" when calling TIFFImageReader.read()
In-Reply-To: <2BFDAA11-750C-4C02-8151-A9755877D9D4@oracle.com>
References: <2BFDAA11-750C-4C02-8151-A9755877D9D4@oracle.com>
Message-ID: <566B5327.7020703@oracle.com>

+1.

-phil.

On 12/11/2015 02:45 PM, Brian Burkhalter wrote:
> Please review at your convenience.
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8144997
> Patch:	http://cr.openjdk.java.net/~bpb/8144997/webrev.00/
>
> Summary:
>
> 1. lines 478-481: If the IFD entry has an unknown data type, skip the entry.
> 2. line 528: if the offset to the field?s value is out of the stream, skip the IFD entry instead of throwing an exception.
>
> Thanks,
>
> Brian



From bourges.laurent at gmail.com  Sat Dec 12 16:17:21 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Sat, 12 Dec 2015 17:17:21 +0100
Subject: [OpenJDK 2D-Dev] RFR 6488522: PNG writer should permit setting
 compression level and iDAT chunk maximum size
In-Reply-To: <CAKjRUT6b6oS7cdJwfCNEWByosnNFogbC2aZ=q-rhGHztqBDBVg@mail.gmail.com>
References: <CAKjRUT4T7L8cK=SP0QM1LK-azLNexA0RNoq2FEFSdbSFetYr6g@mail.gmail.com>
	<56682A5E.6080904@oracle.com>
	<CAKjRUT5fu6fj1ugZ3Yf+C_RzNxRxqVyTb5my2GW5v=jr+n1+dA@mail.gmail.com>
	<566973A2.3000300@oracle.com>
	<CAKjRUT71nwgQKLE0wVOw=7BTbjG2PLZzxwEY7UWuogR_nemx1w@mail.gmail.com>
	<566ABB5A.2070704@oracle.com>
	<CAKjRUT5_dfCGa1Bz9-VYhA2sadoj6L+pejnVTcLGMS84=SNX6A@mail.gmail.com>
	<566AF258.3050008@oracle.com>
	<CAKjRUT6b6oS7cdJwfCNEWByosnNFogbC2aZ=q-rhGHztqBDBVg@mail.gmail.com>
Message-ID: <CAKjRUT6g2u9pHi-wX+U6bSH_A6mRYnbOp94Pp8LR-ZHWRxQE_Q@mail.gmail.com>

Sergey,

Here is my latest webrev:
http://cr.openjdk.java.net/~lbourges/png/PNGWriter-6488522.3/

One more reviewer, please ?


> Probably it can be made local to the write method, but this version looks
fine too.
>
> You're right. I will improve that, I did it too quickly.
>
Fixed: it is clearer and simpler.

Regards,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151212/8642c2f6/attachment.html>

From jayathirth.d.v at oracle.com  Mon Dec 14 09:37:40 2015
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Mon, 14 Dec 2015 01:37:40 -0800 (PST)
Subject: [OpenJDK 2D-Dev] <OpenJDK 2D-Dev> Review request for
 JDK-8143562: JPEG reader returns null for getRawImageType()
In-Reply-To: <5669EE6B.8080802@oracle.com>
References: <45125a5d-a274-4321-9510-dc0e8774d505@default>
	<5667D8D6.3030803@oracle.com> <5669EE6B.8080802@oracle.com>
Message-ID: <7128187f-fe72-410d-9fe9-090b29b39fd0@default>

Hi Phil,

 

I have made changes based on your suggestions.

I have removed specific comment which mentioned about how we handle YCbCr in JPEG and just added common comment(If there is no close match then a type which preserves the most information from the image should be returned) in ImageReader.java.

 

Please find the updated webrev:

http://cr.openjdk.java.net/~jdv/8143562/webrev.01/

 

After technical review is done I will raise CCC request since there is spec change in public API. Please review.

 

Thanks,

Jay

From: Philip Race 
Sent: Friday, December 11, 2015 2:58 AM
To: prasanta sadhukhan
Cc: Jayathirth D V; 2d-dev at openjdk.java.net
Subject: Re: <OpenJDK 2D-Dev> Review request for JDK-8143562: JPEG reader returns null for getRawImageType()

 

The quoted code comment is essentially disclaiming the spec comment.
And the spec. comment is misleading in that it strongly suggests getRawImageType
will hand you an ImageTypeSpecifier representing YCbCr when in fact it does not.

In fact all these comments and behaviours together seem to suggest that there
isn't a consistent view of what should happen here.
- one says we can return something that represents YCbCr
- another says don't add it to the returned list of types because we can't support this raw type after all.
- the spec says return something (anything!) no matter how dissimilar (implied
   by there being at least one (a non-null return)).

Basically that seems to be all the options except supporting it.
All of these need to line up and agree.

So I think we need to update the spec. below to say something like
"Returns an ImageTypeSpecifier indicating the SampleModel and ColorModel
which most closely represents the "raw" internal format of the image.
If there is no close match then a type which preserves the most
information from the image should be returned."

-phil

On 12/8/15, 11:31 PM, prasanta sadhukhan wrote: 

The fix looks good to me. 
The spec says "Returns an ImageTypeSpecifier indicating the SampleModel and ColorModel which most closely represents the "raw" internal format of the image. For example, for a JPEG image the raw type might have a YCbCr color space even though the image would conventionally be transformed into an RGB color space prior to display."
Also, 

private Iterator<ImageTypeSpecifier> getImageTypesOnThread(int imageIndex)adds RGB for YcbCr raw type
case JPEG.JCS_YCbCr:
 832             // As there is no YCbCr ColorSpace, we can't support
 833             // the raw type.
 834 
 835             // due to 4705399, use RGB as default in order to avoid
 836             // slowing down of drawing operations with result image.
 837             list.add(getImageType(JPEG.JCS_RGB));



Regards
Prasanta

On 12/1/2015 3:42 PM, Jayathirth D V wrote:

Hi,

 

Please review following fix in JDK9:

 

Bug : https://bugs.openjdk.java.net/browse/JDK-8143562

 

Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8143562/webrev.00/"http://cr.openjdk.java.net/~jdv/8143562/webrev.00/

 

Issue : We are getting null for ImageTypeSpecifier when we use getRawImageType() API for YCbCr Image.

 

Root cause : When colorspace is YCbCr, there is no condition to create ImageTypeSpecifier in produce() function

 

Solution : Since we add RGB as default ImageType for YCbCr colorspace in getImageTypes() API. Followed same approach

                    and considering it as RGB in getRawImageType().

 

Thanks,

Jay

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151214/2bec30ac/attachment.html>

From james.graham at oracle.com  Tue Dec 15 00:57:44 2015
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 14 Dec 2015 16:57:44 -0800
Subject: [OpenJDK 2D-Dev] Review request for 8069348
 SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D
In-Reply-To: <566B2D68.10201@oracle.com>
References: <564F08B6.7010009@oracle.com> <564F3E8C.3040400@oracle.com>
	<564F4360.3070609@oracle.com> <5654610C.2090302@oracle.com>
	<5654D6F0.3090702@oracle.com> <56582B0E.20405@oracle.com>
	<5658DC90.2010801@oracle.com> <566B2D68.10201@oracle.com>
Message-ID: <566F6588.3080909@oracle.com>

Will OSXOffScreenSurfaceData.copyArea work with a scaled context?  It 
calls the drawImage on the original sg2d, but it is using transformed 
coordinates already.  On the other hand, I installed the patch and built 
on my retina MBP and didn't see any errors in SwingSet2 - is that 
because I was using a different SurfaceData by default (CGL?)?

The rest looks fine...

			...jim

On 12/11/15 12:09 PM, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the updated fix:
> http://cr.openjdk.java.net/~alexsch/8069348/webrev.03
>
> On 28/11/15 02:43, Jim Graham wrote:
>> Hi Alexandr,
>>
>> On 11/27/15 2:06 AM, Alexander Scherbatiy wrote:
>>>> OSXOffscreenSD.java (and all *SD.java), line 481 - should we just make
>>>> this part of the SD.copyArea contract, that the coordinates are in
>>>> device space and the SD method should not concern itself with the SG2D
>>>> transform?
>>>      I updated the SurfaceData.copyArea() x,y,width, and height
>>> description.
>>
>> And yet most of the implementations still check the transformState.
>> Why do they do that if they are no longer concerned with transforming
>> the inputs?
>    Updated.
>
>    XRSurfaceData didn't handled translate scale transform state. I
> removed it and checked that on Linux scaled internal frames are properly
> moved and scroll works correctly.
>    GDIWindowSurfaceData handles only translate state. For scale state
> support it is necessary also to scale destination coordinates. It is
> also requires some additional testing. I left it unchanged.
>>
>>>> CopyAreaTest.java, line 61 - rounding is not the same operation that
>>>> SG2D uses, but it works anyway?
>>
>> The rounding still isn't the same as SG2D.  Floor() != ceil(v - 0.5).
>>
>> On second thought, it's probably best not to worry about the exact
>> rounding in the test case, but just test 1 pixel inset from the
>> coordinates that are needed.  In other words, check:
>>
>> scale(X + (N+1) * DX) + 1
>> scale(Y + (N+1) * DY) + 1,
>> scale(W) - 2
>> scale(H) - 2
>>
>> and go back to just rounding...
>     Updated.
>>
>>>> CopyAreaTest.java, lines 143,144 - why subtract 2DX and 2DY here? Ah,
>>>> this may mask the error in line 94 above...?
>>
>> I notice that it used to check the rectangle at X+(N+1)*DX,
>> Y+(N+1)*DY, but now it only checks X+N*DX,Y+N*DY. Why not continue to
>> check the N+1 copy? That should be the location of the destination of
>> the last copy, right?
>    I believe my initial assumption was incorrect.
>    For example, let's take N = 1. The loops below has only one iteration:
>      -----------
>          for (int i = 0; i < N; i++) {
>              g.copyArea(X + i * DX, Y + i * DY, W, H, DX, DY);
>          }
>      -----------
>
>   Which is just g.copyArea(X, Y, W, H, DX, DY). So the destination
> rectangle is (X+DX, Y+DY, W, H)
>   which corresponds to the N = 1.
>
>   I also updated the test to check different scaleX and scaleY.
>
>   Thanks,
>   Alexandr.
>>
>>             ...jim
>


From Sergey.Bylokhov at oracle.com  Tue Dec 15 15:22:58 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 15 Dec 2015 18:22:58 +0300
Subject: [OpenJDK 2D-Dev] RFR 6488522: PNG writer should permit setting
 compression level and iDAT chunk maximum size
In-Reply-To: <CAKjRUT6g2u9pHi-wX+U6bSH_A6mRYnbOp94Pp8LR-ZHWRxQE_Q@mail.gmail.com>
References: <CAKjRUT4T7L8cK=SP0QM1LK-azLNexA0RNoq2FEFSdbSFetYr6g@mail.gmail.com>
	<56682A5E.6080904@oracle.com>
	<CAKjRUT5fu6fj1ugZ3Yf+C_RzNxRxqVyTb5my2GW5v=jr+n1+dA@mail.gmail.com>
	<566973A2.3000300@oracle.com>
	<CAKjRUT71nwgQKLE0wVOw=7BTbjG2PLZzxwEY7UWuogR_nemx1w@mail.gmail.com>
	<566ABB5A.2070704@oracle.com>
	<CAKjRUT5_dfCGa1Bz9-VYhA2sadoj6L+pejnVTcLGMS84=SNX6A@mail.gmail.com>
	<566AF258.3050008@oracle.com>
	<CAKjRUT6b6oS7cdJwfCNEWByosnNFogbC2aZ=q-rhGHztqBDBVg@mail.gmail.com>
	<CAKjRUT6g2u9pHi-wX+U6bSH_A6mRYnbOp94Pp8LR-ZHWRxQE_Q@mail.gmail.com>
Message-ID: <56703052.5010204@oracle.com>

Looks fine to me. Thanks.

On 12/12/15 19:17, Laurent Bourg?s wrote:
> Sergey,
>
> Here is my latest webrev:
> http://cr.openjdk.java.net/~lbourges/png/PNGWriter-6488522.3/
>
> One more reviewer, please ?
>
>
>> Probably it can be made local to the write method, but this version looks fine too.
>
>     You're right. I will improve that, I did it too quickly.
>
> Fixed: it is clearer and simpler.
>
> Regards,
> Laurent


-- 
Best regards, Sergey.


From bourges.laurent at gmail.com  Tue Dec 15 15:25:58 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 15 Dec 2015 16:25:58 +0100
Subject: [OpenJDK 2D-Dev] RFR 6488522: PNG writer should permit setting
 compression level and iDAT chunk maximum size
In-Reply-To: <56703052.5010204@oracle.com>
References: <CAKjRUT4T7L8cK=SP0QM1LK-azLNexA0RNoq2FEFSdbSFetYr6g@mail.gmail.com>
	<56682A5E.6080904@oracle.com>
	<CAKjRUT5fu6fj1ugZ3Yf+C_RzNxRxqVyTb5my2GW5v=jr+n1+dA@mail.gmail.com>
	<566973A2.3000300@oracle.com>
	<CAKjRUT71nwgQKLE0wVOw=7BTbjG2PLZzxwEY7UWuogR_nemx1w@mail.gmail.com>
	<566ABB5A.2070704@oracle.com>
	<CAKjRUT5_dfCGa1Bz9-VYhA2sadoj6L+pejnVTcLGMS84=SNX6A@mail.gmail.com>
	<566AF258.3050008@oracle.com>
	<CAKjRUT6b6oS7cdJwfCNEWByosnNFogbC2aZ=q-rhGHztqBDBVg@mail.gmail.com>
	<CAKjRUT6g2u9pHi-wX+U6bSH_A6mRYnbOp94Pp8LR-ZHWRxQE_Q@mail.gmail.com>
	<56703052.5010204@oracle.com>
Message-ID: <CAKjRUT5hVA0RxBXOEt=KXKsQv6oqB4DkTx5u-Veadwq1kq+FXw@mail.gmail.com>

Sergey,

thanks for your review.

Could you or Phil push it for me once another reviewer is OK ?

Laurent


2015-12-15 16:22 GMT+01:00 Sergey Bylokhov <Sergey.Bylokhov at oracle.com>:

> Looks fine to me. Thanks.
>
>
> On 12/12/15 19:17, Laurent Bourg?s wrote:
>
>> Sergey,
>>
>> Here is my latest webrev:
>> http://cr.openjdk.java.net/~lbourges/png/PNGWriter-6488522.3/
>>
>> One more reviewer, please ?
>>
>>
>> Probably it can be made local to the write method, but this version looks
>>> fine too.
>>>
>>
>>     You're right. I will improve that, I did it too quickly.
>>
>> Fixed: it is clearer and simpler.
>>
>> Regards,
>> Laurent
>>
>
>
> --
> Best regards, Sergey.
>



-- 
-- 
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151215/97abe8d3/attachment.html>

From philip.race at oracle.com  Tue Dec 15 18:29:57 2015
From: philip.race at oracle.com (Phil Race)
Date: Tue, 15 Dec 2015 10:29:57 -0800
Subject: [OpenJDK 2D-Dev] <OpenJDK 2D-Dev> Review request for
 JDK-8143562: JPEG reader returns null for getRawImageType()
In-Reply-To: <7128187f-fe72-410d-9fe9-090b29b39fd0@default>
References: <45125a5d-a274-4321-9510-dc0e8774d505@default>
	<5667D8D6.3030803@oracle.com> <5669EE6B.8080802@oracle.com>
	<7128187f-fe72-410d-9fe9-090b29b39fd0@default>
Message-ID: <56705C25.6060405@oracle.com>

Looks OK.

-phil.

On 12/14/2015 01:37 AM, Jayathirth D V wrote:
>
> Hi Phil,
>
> I have made changes based on your suggestions.
>
> I have removed specific comment which mentioned about how we handle 
> YCbCr in JPEG and just added common comment(If there is no close match 
> then a type which preserves the most information from the image should 
> be returned) in ImageReader.java.
>
> _Please find the updated webrev:_
>
> http://cr.openjdk.java.net/~jdv/8143562/webrev.01/ 
> <http://cr.openjdk.java.net/%7Ejdv/8143562/webrev.01/>
>
> After technical review is done I will raise CCC request since there is 
> spec change in public API. Please review.
>
> Thanks,
>
> Jay
>
> *From:*Philip Race
> *Sent:* Friday, December 11, 2015 2:58 AM
> *To:* prasanta sadhukhan
> *Cc:* Jayathirth D V; 2d-dev at openjdk.java.net
> *Subject:* Re: <OpenJDK 2D-Dev> Review request for JDK-8143562: JPEG 
> reader returns null for getRawImageType()
>
> The quoted code comment is essentially disclaiming the spec comment.
> And the spec. comment is misleading in that it strongly suggests 
> getRawImageType
> will hand you an ImageTypeSpecifier representing YCbCr when in fact it 
> does not.
>
> In fact all these comments and behaviours together seem to suggest 
> that there
> isn't a consistent view of what should happen here.
> - one says we can return something that represents YCbCr
> - another says don't add it to the returned list of types because we 
> can't support this raw type after all.
> - the spec says return something (anything!) no matter how dissimilar 
> (implied
>    by there being at least one (a non-null return)).
>
> Basically that seems to be all the options except supporting it.
> All of these need to line up and agree.
>
> So I think we need to update the spec. below to say something like
> "Returns an |ImageTypeSpecifier| indicating the |SampleModel| and 
> |ColorModel|
> which most closely represents the "raw" internal format of the image.
> If there is no close match then a type which preserves the most
> information from the image should be returned."
>
> -phil
>
> On 12/8/15, 11:31 PM, prasanta sadhukhan wrote:
>
>     The fix looks good to me.
>     The spec says "Returns an |ImageTypeSpecifier| indicating the
>     |SampleModel| and |ColorModel| which most closely represents the
>     "raw" internal format of the image. For example, for a JPEG image
>     the raw type might have a YCbCr color space even though the image
>     would conventionally be transformed into an RGB color space prior
>     to display."
>     Also,
>
>     private Iterator<ImageTypeSpecifier> getImageTypesOnThread(int imageIndex)adds RGB for YcbCr raw type
>
>     case JPEG.JCS_YCbCr:
>
>       832             // As there is no YCbCr ColorSpace, we can't support
>
>       833             // the raw type.
>
>       834
>
>       835             // due to 4705399, use RGB as default in order to avoid
>
>       836             // slowing down of drawing operations with result image.
>
>       837             list.add(getImageType(JPEG.JCS_RGB));
>
>
>
>     Regards
>     Prasanta
>
>     On 12/1/2015 3:42 PM, Jayathirth D V wrote:
>
>         Hi,
>
>         _Please review following fix in JDK9:_
>
>         Bug : https://bugs.openjdk.java.net/browse/JDK-8143562
>
>         Webrev : http://cr.openjdk.java.net/~jdv/8143562/webrev.00/
>         <http://cr.openjdk.java.net/%7Ejdv/8143562/webrev.00/>
>
>         Issue : We are getting null for ImageTypeSpecifier when we use
>         getRawImageType() API for YCbCr Image.
>
>         Root cause : When colorspace is YCbCr, there is no condition
>         to create ImageTypeSpecifier in produce() function
>
>         Solution : Since we add RGB as default ImageType for YCbCr
>         colorspace in getImageTypes() API. Followed same approach
>
>                             and considering it as RGB in
>         getRawImageType().
>
>         Thanks,
>
>         Jay
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151215/fb474a98/attachment.html>

From james.graham at oracle.com  Tue Dec 15 19:22:18 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 15 Dec 2015 11:22:18 -0800
Subject: [OpenJDK 2D-Dev] Review request for 8069348
 SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D
In-Reply-To: <566F6588.3080909@oracle.com>
References: <564F08B6.7010009@oracle.com> <564F3E8C.3040400@oracle.com>
	<564F4360.3070609@oracle.com> <5654610C.2090302@oracle.com>
	<5654D6F0.3090702@oracle.com> <56582B0E.20405@oracle.com>
	<5658DC90.2010801@oracle.com> <566B2D68.10201@oracle.com>
	<566F6588.3080909@oracle.com>
Message-ID: <5670686A.8040904@oracle.com>

Also, X11SD and GDISD still reject TRANSLATESCALE.

I think it may make sense for OSXOffscreen to return false for 
TRANSLATESCALE and punt back to the general implementation?  But, X11 
and GDI should be able to allow that condition...

			...jim

On 12/14/15 4:57 PM, Jim Graham wrote:
> Will OSXOffScreenSurfaceData.copyArea work with a scaled context?  It
> calls the drawImage on the original sg2d, but it is using transformed
> coordinates already.  On the other hand, I installed the patch and built
> on my retina MBP and didn't see any errors in SwingSet2 - is that
> because I was using a different SurfaceData by default (CGL?)?
>
> The rest looks fine...
>
>              ...jim
>
> On 12/11/15 12:09 PM, Alexander Scherbatiy wrote:
>>
>> Hello,
>>
>> Could you review the updated fix:
>> http://cr.openjdk.java.net/~alexsch/8069348/webrev.03
>>
>> On 28/11/15 02:43, Jim Graham wrote:
>>> Hi Alexandr,
>>>
>>> On 11/27/15 2:06 AM, Alexander Scherbatiy wrote:
>>>>> OSXOffscreenSD.java (and all *SD.java), line 481 - should we just make
>>>>> this part of the SD.copyArea contract, that the coordinates are in
>>>>> device space and the SD method should not concern itself with the SG2D
>>>>> transform?
>>>>      I updated the SurfaceData.copyArea() x,y,width, and height
>>>> description.
>>>
>>> And yet most of the implementations still check the transformState.
>>> Why do they do that if they are no longer concerned with transforming
>>> the inputs?
>>    Updated.
>>
>>    XRSurfaceData didn't handled translate scale transform state. I
>> removed it and checked that on Linux scaled internal frames are properly
>> moved and scroll works correctly.
>>    GDIWindowSurfaceData handles only translate state. For scale state
>> support it is necessary also to scale destination coordinates. It is
>> also requires some additional testing. I left it unchanged.
>>>
>>>>> CopyAreaTest.java, line 61 - rounding is not the same operation that
>>>>> SG2D uses, but it works anyway?
>>>
>>> The rounding still isn't the same as SG2D.  Floor() != ceil(v - 0.5).
>>>
>>> On second thought, it's probably best not to worry about the exact
>>> rounding in the test case, but just test 1 pixel inset from the
>>> coordinates that are needed.  In other words, check:
>>>
>>> scale(X + (N+1) * DX) + 1
>>> scale(Y + (N+1) * DY) + 1,
>>> scale(W) - 2
>>> scale(H) - 2
>>>
>>> and go back to just rounding...
>>     Updated.
>>>
>>>>> CopyAreaTest.java, lines 143,144 - why subtract 2DX and 2DY here? Ah,
>>>>> this may mask the error in line 94 above...?
>>>
>>> I notice that it used to check the rectangle at X+(N+1)*DX,
>>> Y+(N+1)*DY, but now it only checks X+N*DX,Y+N*DY. Why not continue to
>>> check the N+1 copy? That should be the location of the destination of
>>> the last copy, right?
>>    I believe my initial assumption was incorrect.
>>    For example, let's take N = 1. The loops below has only one iteration:
>>      -----------
>>          for (int i = 0; i < N; i++) {
>>              g.copyArea(X + i * DX, Y + i * DY, W, H, DX, DY);
>>          }
>>      -----------
>>
>>   Which is just g.copyArea(X, Y, W, H, DX, DY). So the destination
>> rectangle is (X+DX, Y+DY, W, H)
>>   which corresponds to the N = 1.
>>
>>   I also updated the test to check different scaleX and scaleY.
>>
>>   Thanks,
>>   Alexandr.
>>>
>>>             ...jim
>>


From Sergey.Bylokhov at oracle.com  Tue Dec 15 19:30:27 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 15 Dec 2015 22:30:27 +0300
Subject: [OpenJDK 2D-Dev] Review request for 8069348
 SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D
In-Reply-To: <566F6588.3080909@oracle.com>
References: <564F08B6.7010009@oracle.com> <564F3E8C.3040400@oracle.com>
	<564F4360.3070609@oracle.com> <5654610C.2090302@oracle.com>
	<5654D6F0.3090702@oracle.com> <56582B0E.20405@oracle.com>
	<5658DC90.2010801@oracle.com> <566B2D68.10201@oracle.com>
	<566F6588.3080909@oracle.com>
Message-ID: <56706A53.9090207@oracle.com>

On 15/12/15 03:57, Jim Graham wrote:
> Will OSXOffScreenSurfaceData.copyArea work with a scaled context?  It
> calls the drawImage on the original sg2d, but it is using transformed
> coordinates already.  On the other hand, I installed the patch and built
> on my retina MBP and didn't see any errors in SwingSet2 - is that
> because I was using a different SurfaceData by default (CGL?)?

OSXOffScreenSurfaceData and other classes are a part of the old quartz 
based pipeline. These classes were added to the jdk as part of the 
printing support on the osx. As far as I know the printing support was 
copied as is from jdk6 and I am not sure that all of these files are 
used right now.

>
> The rest looks fine...
>
>              ...jim
>
> On 12/11/15 12:09 PM, Alexander Scherbatiy wrote:
>>
>> Hello,
>>
>> Could you review the updated fix:
>> http://cr.openjdk.java.net/~alexsch/8069348/webrev.03
>>
>> On 28/11/15 02:43, Jim Graham wrote:
>>> Hi Alexandr,
>>>
>>> On 11/27/15 2:06 AM, Alexander Scherbatiy wrote:
>>>>> OSXOffscreenSD.java (and all *SD.java), line 481 - should we just make
>>>>> this part of the SD.copyArea contract, that the coordinates are in
>>>>> device space and the SD method should not concern itself with the SG2D
>>>>> transform?
>>>>      I updated the SurfaceData.copyArea() x,y,width, and height
>>>> description.
>>>
>>> And yet most of the implementations still check the transformState.
>>> Why do they do that if they are no longer concerned with transforming
>>> the inputs?
>>    Updated.
>>
>>    XRSurfaceData didn't handled translate scale transform state. I
>> removed it and checked that on Linux scaled internal frames are properly
>> moved and scroll works correctly.
>>    GDIWindowSurfaceData handles only translate state. For scale state
>> support it is necessary also to scale destination coordinates. It is
>> also requires some additional testing. I left it unchanged.
>>>
>>>>> CopyAreaTest.java, line 61 - rounding is not the same operation that
>>>>> SG2D uses, but it works anyway?
>>>
>>> The rounding still isn't the same as SG2D.  Floor() != ceil(v - 0.5).
>>>
>>> On second thought, it's probably best not to worry about the exact
>>> rounding in the test case, but just test 1 pixel inset from the
>>> coordinates that are needed.  In other words, check:
>>>
>>> scale(X + (N+1) * DX) + 1
>>> scale(Y + (N+1) * DY) + 1,
>>> scale(W) - 2
>>> scale(H) - 2
>>>
>>> and go back to just rounding...
>>     Updated.
>>>
>>>>> CopyAreaTest.java, lines 143,144 - why subtract 2DX and 2DY here? Ah,
>>>>> this may mask the error in line 94 above...?
>>>
>>> I notice that it used to check the rectangle at X+(N+1)*DX,
>>> Y+(N+1)*DY, but now it only checks X+N*DX,Y+N*DY. Why not continue to
>>> check the N+1 copy? That should be the location of the destination of
>>> the last copy, right?
>>    I believe my initial assumption was incorrect.
>>    For example, let's take N = 1. The loops below has only one iteration:
>>      -----------
>>          for (int i = 0; i < N; i++) {
>>              g.copyArea(X + i * DX, Y + i * DY, W, H, DX, DY);
>>          }
>>      -----------
>>
>>   Which is just g.copyArea(X, Y, W, H, DX, DY). So the destination
>> rectangle is (X+DX, Y+DY, W, H)
>>   which corresponds to the N = 1.
>>
>>   I also updated the test to check different scaleX and scaleY.
>>
>>   Thanks,
>>   Alexandr.
>>>
>>>             ...jim
>>


-- 
Best regards, Sergey.


From james.graham at oracle.com  Tue Dec 15 19:33:15 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 15 Dec 2015 11:33:15 -0800
Subject: [OpenJDK 2D-Dev] Review request for 8069348
 SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D
In-Reply-To: <56706A53.9090207@oracle.com>
References: <564F08B6.7010009@oracle.com> <564F3E8C.3040400@oracle.com>
	<564F4360.3070609@oracle.com> <5654610C.2090302@oracle.com>
	<5654D6F0.3090702@oracle.com> <56582B0E.20405@oracle.com>
	<5658DC90.2010801@oracle.com> <566B2D68.10201@oracle.com>
	<566F6588.3080909@oracle.com> <56706A53.9090207@oracle.com>
Message-ID: <56706AFB.7060407@oracle.com>

A safer approach may be to punt for that implementation if there is no 
strong argument for having an optimized copyArea there.  How sure or not 
sure are you that this is still used?

			...jim

On 12/15/15 11:30 AM, Sergey Bylokhov wrote:
> On 15/12/15 03:57, Jim Graham wrote:
>> Will OSXOffScreenSurfaceData.copyArea work with a scaled context?  It
>> calls the drawImage on the original sg2d, but it is using transformed
>> coordinates already.  On the other hand, I installed the patch and built
>> on my retina MBP and didn't see any errors in SwingSet2 - is that
>> because I was using a different SurfaceData by default (CGL?)?
>
> OSXOffScreenSurfaceData and other classes are a part of the old quartz
> based pipeline. These classes were added to the jdk as part of the
> printing support on the osx. As far as I know the printing support was
> copied as is from jdk6 and I am not sure that all of these files are
> used right now.
>
>>
>> The rest looks fine...
>>
>>              ...jim
>>
>> On 12/11/15 12:09 PM, Alexander Scherbatiy wrote:
>>>
>>> Hello,
>>>
>>> Could you review the updated fix:
>>> http://cr.openjdk.java.net/~alexsch/8069348/webrev.03
>>>
>>> On 28/11/15 02:43, Jim Graham wrote:
>>>> Hi Alexandr,
>>>>
>>>> On 11/27/15 2:06 AM, Alexander Scherbatiy wrote:
>>>>>> OSXOffscreenSD.java (and all *SD.java), line 481 - should we just
>>>>>> make
>>>>>> this part of the SD.copyArea contract, that the coordinates are in
>>>>>> device space and the SD method should not concern itself with the
>>>>>> SG2D
>>>>>> transform?
>>>>>      I updated the SurfaceData.copyArea() x,y,width, and height
>>>>> description.
>>>>
>>>> And yet most of the implementations still check the transformState.
>>>> Why do they do that if they are no longer concerned with transforming
>>>> the inputs?
>>>    Updated.
>>>
>>>    XRSurfaceData didn't handled translate scale transform state. I
>>> removed it and checked that on Linux scaled internal frames are properly
>>> moved and scroll works correctly.
>>>    GDIWindowSurfaceData handles only translate state. For scale state
>>> support it is necessary also to scale destination coordinates. It is
>>> also requires some additional testing. I left it unchanged.
>>>>
>>>>>> CopyAreaTest.java, line 61 - rounding is not the same operation that
>>>>>> SG2D uses, but it works anyway?
>>>>
>>>> The rounding still isn't the same as SG2D.  Floor() != ceil(v - 0.5).
>>>>
>>>> On second thought, it's probably best not to worry about the exact
>>>> rounding in the test case, but just test 1 pixel inset from the
>>>> coordinates that are needed.  In other words, check:
>>>>
>>>> scale(X + (N+1) * DX) + 1
>>>> scale(Y + (N+1) * DY) + 1,
>>>> scale(W) - 2
>>>> scale(H) - 2
>>>>
>>>> and go back to just rounding...
>>>     Updated.
>>>>
>>>>>> CopyAreaTest.java, lines 143,144 - why subtract 2DX and 2DY here? Ah,
>>>>>> this may mask the error in line 94 above...?
>>>>
>>>> I notice that it used to check the rectangle at X+(N+1)*DX,
>>>> Y+(N+1)*DY, but now it only checks X+N*DX,Y+N*DY. Why not continue to
>>>> check the N+1 copy? That should be the location of the destination of
>>>> the last copy, right?
>>>    I believe my initial assumption was incorrect.
>>>    For example, let's take N = 1. The loops below has only one
>>> iteration:
>>>      -----------
>>>          for (int i = 0; i < N; i++) {
>>>              g.copyArea(X + i * DX, Y + i * DY, W, H, DX, DY);
>>>          }
>>>      -----------
>>>
>>>   Which is just g.copyArea(X, Y, W, H, DX, DY). So the destination
>>> rectangle is (X+DX, Y+DY, W, H)
>>>   which corresponds to the N = 1.
>>>
>>>   I also updated the test to check different scaleX and scaleY.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>>
>>>>             ...jim
>>>
>
>


From james.graham at oracle.com  Tue Dec 15 20:42:12 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 15 Dec 2015 12:42:12 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144718: Pisces / Marlin Strokers may
 generate invalid curves with huge coordinates and round joins
In-Reply-To: <566632AD.4000908@oracle.com>
References: <CAKjRUT6U8+DWi8DQuWuRwQFoKVMwR8hpHFD36isDxDcw-6F-Dw@mail.gmail.com>
	<56621B00.9090309@oracle.com>
	<CAKjRUT7KPBQ+g7aQ1Qsco-FBuxNAT9COKHn+gMsDAyJKmFYC6g@mail.gmail.com>
	<566632AD.4000908@oracle.com>
Message-ID: <56707B24.2020405@oracle.com>

On second thought - it would be good to remove the dependency on the 
font from the test case since that can change over time and we'd no 
longer have the regression test we once had...

			...jim

On 12/7/15 5:30 PM, Jim Graham wrote:
> Looks good.
>
>          ...jim
>
> On 12/5/15 8:33 AM, Laurent Bourg?s wrote:
>> Jim,
>>
>> here is the updated webrev:
>> http://cr.openjdk.java.net/~lbourges/marlin/Stroker-8144718.1/
>>
>> Changes:
>> - added the comment you proposed
>> - Marlin: use precomputed invHalfLineWidth2Sq = 1f / (2f * lineWidth2 *
>> lineWidth2) for performance
>> - fix copyright date in Pisces Stroker
>>
>> Laurent
>>
>> 2015-12-05 0:00 GMT+01:00 Jim Graham <james.graham at oracle.com
>> <mailto:james.graham at oracle.com>>:
>>
>>     I'd make the test >= 0.5 since 0.5 generates a flat curve as well.
>>
>>     And it couldn't hurt to mention that we are worried about round off
>>     error since someone coming along might wonder why we're worried that
>>     a cos() is > 1:
>>
>>     // check round off errors producing cos(ext) > 1 and a NaN below
>>     // cos(ext) == 1 implies colinear segments and an empty join anyway
>>
>>                      ...jim
>>
>>
>>     On 12/4/15 8:33 AM, Laurent Bourg?s wrote:
>>
>>         Hi,
>>
>>         Please review this webrev  fixing the Stroker bug in both
>> Pisces &
>>         Marlin (same changes):
>>         bug: https://bugs.openjdk.java.net/browse/JDK-8144718
>>         webrev:
>>         http://cr.openjdk.java.net/~lbourges/marlin/Stroker-8144718.0/
>>
>>         As this bug is very difficult to reproduce (artefacts), I just
>>         provide a
>>         simple test class that reproduces the issue.
>>
>>         Regards,
>>         Laurent Bourg?s
>>
>>
>>
>>
>> --
>> --
>> Laurent Bourg?s


From bourges.laurent at gmail.com  Tue Dec 15 22:06:34 2015
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 15 Dec 2015 23:06:34 +0100
Subject: [OpenJDK 2D-Dev] RFR 8144718: Pisces / Marlin Strokers may
 generate invalid curves with huge coordinates and round joins
In-Reply-To: <56707B24.2020405@oracle.com>
References: <CAKjRUT6U8+DWi8DQuWuRwQFoKVMwR8hpHFD36isDxDcw-6F-Dw@mail.gmail.com>
	<56621B00.9090309@oracle.com>
	<CAKjRUT7KPBQ+g7aQ1Qsco-FBuxNAT9COKHn+gMsDAyJKmFYC6g@mail.gmail.com>
	<566632AD.4000908@oracle.com> <56707B24.2020405@oracle.com>
Message-ID: <CAKjRUT6W_kC3ftrOu+=xNbxFQYqE61Ki8zSmZ1gb0aAP_cGNig@mail.gmail.com>

Jim & Phil,

Here is an updated webrev:
http://cr.openjdk.java.net/~lbourges/marlin/Stroker-8144718.3/

I have totally rewritten the test to:
- enable Marlin doChecks=true
- use Marlin logger + custom handler to detect any failure in
XxxArrayCache.check()
- serialize the 'bad' shape into java code: see serialize(shape) and
derserialize()

In conclusion, the improved test fails without the fix and no more need any
font (embedded shape in the java code).

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151215/f19a592b/attachment.html>

From james.graham at oracle.com  Tue Dec 15 23:32:14 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 15 Dec 2015 15:32:14 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144718: Pisces / Marlin Strokers may
 generate invalid curves with huge coordinates and round joins
In-Reply-To: <CAKjRUT6W_kC3ftrOu+=xNbxFQYqE61Ki8zSmZ1gb0aAP_cGNig@mail.gmail.com>
References: <CAKjRUT6U8+DWi8DQuWuRwQFoKVMwR8hpHFD36isDxDcw-6F-Dw@mail.gmail.com>
	<56621B00.9090309@oracle.com>
	<CAKjRUT7KPBQ+g7aQ1Qsco-FBuxNAT9COKHn+gMsDAyJKmFYC6g@mail.gmail.com>
	<566632AD.4000908@oracle.com> <56707B24.2020405@oracle.com>
	<CAKjRUT6W_kC3ftrOu+=xNbxFQYqE61Ki8zSmZ1gb0aAP_cGNig@mail.gmail.com>
Message-ID: <5670A2FE.8070904@oracle.com>

That's a lot of test case for one path, but it does indeed fail before 
and pass after the fix so it looks like it does the job.

+1 from me.

			...jim

On 12/15/15 2:06 PM, Laurent Bourg?s wrote:
> Jim & Phil,
>
> Here is an updated webrev:
> http://cr.openjdk.java.net/~lbourges/marlin/Stroker-8144718.3/
>
> I have totally rewritten the test to:
> - enable Marlin doChecks=true
> - use Marlin logger + custom handler to detect any failure in
> XxxArrayCache.check()
> - serialize the 'bad' shape into java code: see serialize(shape) and
> derserialize()
>
> In conclusion, the improved test fails without the fix and no more need
> any font (embedded shape in the java code).
>
> Cheers,
> Laurent


From jayathirth.d.v at oracle.com  Wed Dec 16 09:27:14 2015
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Wed, 16 Dec 2015 01:27:14 -0800 (PST)
Subject: [OpenJDK 2D-Dev] <OpenJDK 2D-Dev> Review request for
 JDK-8143562: JPEG reader returns null for getRawImageType()
In-Reply-To: <56705C25.6060405@oracle.com>
References: <45125a5d-a274-4321-9510-dc0e8774d505@default>
	<5667D8D6.3030803@oracle.com> <5669EE6B.8080802@oracle.com>
	<7128187f-fe72-410d-9fe9-090b29b39fd0@default>
	<56705C25.6060405@oracle.com>
Message-ID: <4c784b81-de98-48af-b27d-421bbec2952e@default>

Thanks for the review Phil.

Can I get one more review for new webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8143562/webrev.01/"http://cr.openjdk.java.net/~jdv/8143562/webrev.01/

 

Regards,

Jay

 

From: Phil Race 
Sent: Wednesday, December 16, 2015 12:00 AM
To: Jayathirth D V
Cc: 2d-dev at openjdk.java.net; brian Burkhalter
Subject: Re: <OpenJDK 2D-Dev> Review request for JDK-8143562: JPEG reader returns null for getRawImageType()

 

Looks OK.

-phil.

On 12/14/2015 01:37 AM, Jayathirth D V wrote:

Hi Phil,

 

I have made changes based on your suggestions.

I have removed specific comment which mentioned about how we handle YCbCr in JPEG and just added common comment(If there is no close match then a type which preserves the most information from the image should be returned) in ImageReader.java.

 

Please find the updated webrev:

HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8143562/webrev.01/"http://cr.openjdk.java.net/~jdv/8143562/webrev.01/

 

After technical review is done I will raise CCC request since there is spec change in public API. Please review.

 

Thanks,

Jay

From: Philip Race 
Sent: Friday, December 11, 2015 2:58 AM
To: prasanta sadhukhan
Cc: Jayathirth D V; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net
Subject: Re: <OpenJDK 2D-Dev> Review request for JDK-8143562: JPEG reader returns null for getRawImageType()

 

The quoted code comment is essentially disclaiming the spec comment.
And the spec. comment is misleading in that it strongly suggests getRawImageType
will hand you an ImageTypeSpecifier representing YCbCr when in fact it does not.

In fact all these comments and behaviours together seem to suggest that there
isn't a consistent view of what should happen here.
- one says we can return something that represents YCbCr
- another says don't add it to the returned list of types because we can't support this raw type after all.
- the spec says return something (anything!) no matter how dissimilar (implied
   by there being at least one (a non-null return)).

Basically that seems to be all the options except supporting it.
All of these need to line up and agree.

So I think we need to update the spec. below to say something like
"Returns an ImageTypeSpecifier indicating the SampleModel and ColorModel
which most closely represents the "raw" internal format of the image.
If there is no close match then a type which preserves the most
information from the image should be returned."

-phil

On 12/8/15, 11:31 PM, prasanta sadhukhan wrote: 

The fix looks good to me. 
The spec says "Returns an ImageTypeSpecifier indicating the SampleModel and ColorModel which most closely represents the "raw" internal format of the image. For example, for a JPEG image the raw type might have a YCbCr color space even though the image would conventionally be transformed into an RGB color space prior to display."
Also, 

private Iterator<ImageTypeSpecifier> getImageTypesOnThread(int imageIndex)adds RGB for YcbCr raw type
case JPEG.JCS_YCbCr:
 832             // As there is no YCbCr ColorSpace, we can't support
 833             // the raw type.
 834 
 835             // due to 4705399, use RGB as default in order to avoid
 836             // slowing down of drawing operations with result image.
 837             list.add(getImageType(JPEG.JCS_RGB));



Regards
Prasanta

On 12/1/2015 3:42 PM, Jayathirth D V wrote:

Hi,

 

Please review following fix in JDK9:

 

Bug : https://bugs.openjdk.java.net/browse/JDK-8143562

 

Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8143562/webrev.00/"http://cr.openjdk.java.net/~jdv/8143562/webrev.00/

 

Issue : We are getting null for ImageTypeSpecifier when we use getRawImageType() API for YCbCr Image.

 

Root cause : When colorspace is YCbCr, there is no condition to create ImageTypeSpecifier in produce() function

 

Solution : Since we add RGB as default ImageType for YCbCr colorspace in getImageTypes() API. Followed same approach

                    and considering it as RGB in getRawImageType().

 

Thanks,

Jay

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151216/365af870/attachment.html>

From philip.race at oracle.com  Wed Dec 16 20:53:49 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 16 Dec 2015 12:53:49 -0800
Subject: [OpenJDK 2D-Dev] RFR 8144718: Pisces / Marlin Strokers may
 generate invalid curves with huge coordinates and round joins
In-Reply-To: <CAKjRUT6W_kC3ftrOu+=xNbxFQYqE61Ki8zSmZ1gb0aAP_cGNig@mail.gmail.com>
References: <CAKjRUT6U8+DWi8DQuWuRwQFoKVMwR8hpHFD36isDxDcw-6F-Dw@mail.gmail.com>
	<56621B00.9090309@oracle.com>
	<CAKjRUT7KPBQ+g7aQ1Qsco-FBuxNAT9COKHn+gMsDAyJKmFYC6g@mail.gmail.com>
	<566632AD.4000908@oracle.com> <56707B24.2020405@oracle.com>
	<CAKjRUT6W_kC3ftrOu+=xNbxFQYqE61Ki8zSmZ1gb0aAP_cGNig@mail.gmail.com>
Message-ID: <5671CF5D.3080702@oracle.com>

+1.

-phil.

On 12/15/2015 02:06 PM, Laurent Bourg?s wrote:
> Jim & Phil,
>
> Here is an updated webrev:
> http://cr.openjdk.java.net/~lbourges/marlin/Stroker-8144718.3/ 
> <http://cr.openjdk.java.net/%7Elbourges/marlin/Stroker-8144718.3/>
>
> I have totally rewritten the test to:
> - enable Marlin doChecks=true
> - use Marlin logger + custom handler to detect any failure in 
> XxxArrayCache.check()
> - serialize the 'bad' shape into java code: see serialize(shape) and 
> derserialize()
>
> In conclusion, the improved test fails without the fix and no more 
> need any font (embedded shape in the java code).
>
> Cheers,
> Laurent



From philip.race at oracle.com  Wed Dec 16 21:12:05 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 16 Dec 2015 13:12:05 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8145584:
 java/awt/font/TextLayout/TestGetPixelBounds.java fails on Linux
Message-ID: <5671D3A5.2000009@oracle.com>

http://cr.openjdk.java.net/~prr/8145584/
https://bugs.openjdk.java.net/browse/JDK-8145584

The bug is that the code that tries to measure where the bounds
of the rendering is not applying the same  rounding of the rendering
position as the rendering path does. It seems this test was just
waiting for the right circumstances to come along to expose the bug.

The test that fails was closed but I have determined we are OK to open it.

-phil.


From philip.race at oracle.com  Wed Dec 16 22:31:35 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 16 Dec 2015 14:31:35 -0800
Subject: [OpenJDK 2D-Dev] RFR 6488522: PNG writer should permit setting
 compression level and iDAT chunk maximum size
In-Reply-To: <CAKjRUT5hVA0RxBXOEt=KXKsQv6oqB4DkTx5u-Veadwq1kq+FXw@mail.gmail.com>
References: <CAKjRUT4T7L8cK=SP0QM1LK-azLNexA0RNoq2FEFSdbSFetYr6g@mail.gmail.com>
	<56682A5E.6080904@oracle.com>
	<CAKjRUT5fu6fj1ugZ3Yf+C_RzNxRxqVyTb5my2GW5v=jr+n1+dA@mail.gmail.com>
	<566973A2.3000300@oracle.com>
	<CAKjRUT71nwgQKLE0wVOw=7BTbjG2PLZzxwEY7UWuogR_nemx1w@mail.gmail.com>
	<566ABB5A.2070704@oracle.com>
	<CAKjRUT5_dfCGa1Bz9-VYhA2sadoj6L+pejnVTcLGMS84=SNX6A@mail.gmail.com>
	<566AF258.3050008@oracle.com>
	<CAKjRUT6b6oS7cdJwfCNEWByosnNFogbC2aZ=q-rhGHztqBDBVg@mail.gmail.com>
	<CAKjRUT6g2u9pHi-wX+U6bSH_A6mRYnbOp94Pp8LR-ZHWRxQE_Q@mail.gmail.com>
	<56703052.5010204@oracle.com>
	<CAKjRUT5hVA0RxBXOEt=KXKsQv6oqB4DkTx5u-Veadwq1kq+FXw@mail.gmail.com>
Message-ID: <5671E647.5060102@oracle.com>

Looks good. I will push it shortly.

-phil.

On 12/15/2015 07:25 AM, Laurent Bourg?s wrote:
> Sergey,
>
> thanks for your review.
>
> Could you or Phil push it for me once another reviewer is OK ?
>
> Laurent
>
>
> 2015-12-15 16:22 GMT+01:00 Sergey Bylokhov <Sergey.Bylokhov at oracle.com 
> <mailto:Sergey.Bylokhov at oracle.com>>:
>
>     Looks fine to me. Thanks.
>
>
>     On 12/12/15 19:17, Laurent Bourg?s wrote:
>
>         Sergey,
>
>         Here is my latest webrev:
>         http://cr.openjdk.java.net/~lbourges/png/PNGWriter-6488522.3/
>         <http://cr.openjdk.java.net/%7Elbourges/png/PNGWriter-6488522.3/>
>
>         One more reviewer, please ?
>
>
>             Probably it can be made local to the write method, but
>             this version looks fine too.
>
>
>             You're right. I will improve that, I did it too quickly.
>
>         Fixed: it is clearer and simpler.
>
>         Regards,
>         Laurent
>
>
>
>     -- 
>     Best regards, Sergey.
>
>
>
>
> -- 
> -- 
> Laurent Bourg?s

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151216/bc8d0ee6/attachment.html>

From ambarish.rapte at oracle.com  Thu Dec 17 06:34:09 2015
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Wed, 16 Dec 2015 22:34:09 -0800 (PST)
Subject: [OpenJDK 2D-Dev] <OpenJDK 2D-Dev> Review request for
 JDK-8143562: JPEG reader returns null for getRawImageType()
In-Reply-To: <4c784b81-de98-48af-b27d-421bbec2952e@default>
References: <45125a5d-a274-4321-9510-dc0e8774d505@default>
	<5667D8D6.3030803@oracle.com> <5669EE6B.8080802@oracle.com>
	<7128187f-fe72-410d-9fe9-090b29b39fd0@default>
	<56705C25.6060405@oracle.com>
	<4c784b81-de98-48af-b27d-421bbec2952e@default>
Message-ID: <a081bcfe-84a5-41d3-8c91-bba99efbf940@default>

Hi Jay,

                

                As per the specification getRawImageType() should return a valid ImageTypeSpecifier for each color space,  which was missing for YCbCr.

This patch fixes the issue & seems fine to me.

                

 

Thanks,

Ambarish

 

 

From: Jayathirth D V 
Sent: Wednesday, December 16, 2015 2:57 PM
To: Philip Race
Cc: 2d-dev at openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] <OpenJDK 2D-Dev> Review request for JDK-8143562: JPEG reader returns null for getRawImageType()

 

Thanks for the review Phil.

Can I get one more review for new webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8143562/webrev.01/"http://cr.openjdk.java.net/~jdv/8143562/webrev.01/

 

Regards,

Jay

 

From: Phil Race 
Sent: Wednesday, December 16, 2015 12:00 AM
To: Jayathirth D V
Cc: HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net; brian Burkhalter
Subject: Re: <OpenJDK 2D-Dev> Review request for JDK-8143562: JPEG reader returns null for getRawImageType()

 

Looks OK.

-phil.

On 12/14/2015 01:37 AM, Jayathirth D V wrote:

Hi Phil,

 

I have made changes based on your suggestions.

I have removed specific comment which mentioned about how we handle YCbCr in JPEG and just added common comment(If there is no close match then a type which preserves the most information from the image should be returned) in ImageReader.java.

 

Please find the updated webrev:

HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8143562/webrev.01/"http://cr.openjdk.java.net/~jdv/8143562/webrev.01/

 

After technical review is done I will raise CCC request since there is spec change in public API. Please review.

 

Thanks,

Jay

From: Philip Race 
Sent: Friday, December 11, 2015 2:58 AM
To: prasanta sadhukhan
Cc: Jayathirth D V; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net
Subject: Re: <OpenJDK 2D-Dev> Review request for JDK-8143562: JPEG reader returns null for getRawImageType()

 

The quoted code comment is essentially disclaiming the spec comment.
And the spec. comment is misleading in that it strongly suggests getRawImageType
will hand you an ImageTypeSpecifier representing YCbCr when in fact it does not.

In fact all these comments and behaviours together seem to suggest that there
isn't a consistent view of what should happen here.
- one says we can return something that represents YCbCr
- another says don't add it to the returned list of types because we can't support this raw type after all.
- the spec says return something (anything!) no matter how dissimilar (implied
   by there being at least one (a non-null return)).

Basically that seems to be all the options except supporting it.
All of these need to line up and agree.

So I think we need to update the spec. below to say something like
"Returns an ImageTypeSpecifier indicating the SampleModel and ColorModel
which most closely represents the "raw" internal format of the image.
If there is no close match then a type which preserves the most
information from the image should be returned."

-phil

On 12/8/15, 11:31 PM, prasanta sadhukhan wrote: 

The fix looks good to me. 
The spec says "Returns an ImageTypeSpecifier indicating the SampleModel and ColorModel which most closely represents the "raw" internal format of the image. For example, for a JPEG image the raw type might have a YCbCr color space even though the image would conventionally be transformed into an RGB color space prior to display."
Also, 

private Iterator<ImageTypeSpecifier> getImageTypesOnThread(int imageIndex)adds RGB for YcbCr raw type
case JPEG.JCS_YCbCr:
 832             // As there is no YCbCr ColorSpace, we can't support
 833             // the raw type.
 834 
 835             // due to 4705399, use RGB as default in order to avoid
 836             // slowing down of drawing operations with result image.
 837             list.add(getImageType(JPEG.JCS_RGB));



Regards
Prasanta

On 12/1/2015 3:42 PM, Jayathirth D V wrote:

Hi,

 

Please review following fix in JDK9:

 

Bug : https://bugs.openjdk.java.net/browse/JDK-8143562

 

Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8143562/webrev.00/"http://cr.openjdk.java.net/~jdv/8143562/webrev.00/

 

Issue : We are getting null for ImageTypeSpecifier when we use getRawImageType() API for YCbCr Image.

 

Root cause : When colorspace is YCbCr, there is no condition to create ImageTypeSpecifier in produce() function

 

Solution : Since we add RGB as default ImageType for YCbCr colorspace in getImageTypes() API. Followed same approach

                    and considering it as RGB in getRawImageType().

 

Thanks,

Jay

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151216/a3e5be4a/attachment.html>

From philip.race at oracle.com  Fri Dec 18 19:59:10 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 18 Dec 2015 11:59:10 -0800
Subject: [OpenJDK 2D-Dev] RFR 8145785: [TEST_BUG]
 java/awt/Toolkit/GetSizeTest/GetScreenSizeTest.java: incorrect name
Message-ID: <5674658E.30507@oracle.com>

Please review simple fix (in-line below) to a test

-phil.

https://bugs.openjdk.java.net/browse/JDK-8145785

--- a/test/java/awt/Toolkit/GetSizeTest/GetScreenSizeTest.java
+++ b/test/java/awt/Toolkit/GetSizeTest/GetScreenSizeTest.java
@@ -23,12 +23,12 @@

  /*
    @test
-  @bug 8144074
+  @bug 8144074 8145785
    @summary Crash while getting screen size during Toolkit initialisation
-  @run main/othervm GetScreenSize
+  @run main/othervm GetScreenSizeTest
  */

-public class GetScreenSize {
+public class GetScreenSizeTest {
      public static void main(String[] args) {
          java.awt.Toolkit.getDefaultToolkit().getScreenSize();
      }



From Sergey.Bylokhov at oracle.com  Fri Dec 18 21:50:35 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 19 Dec 2015 00:50:35 +0300
Subject: [OpenJDK 2D-Dev] RFR 8145785: [TEST_BUG]
 java/awt/Toolkit/GetSizeTest/GetScreenSizeTest.java: incorrect name
In-Reply-To: <5674658E.30507@oracle.com>
References: <5674658E.30507@oracle.com>
Message-ID: <56747FAB.7030005@oracle.com>

Looks fine.

On 18/12/15 22:59, Phil Race wrote:
> Please review simple fix (in-line below) to a test
>
> -phil.
>
> https://bugs.openjdk.java.net/browse/JDK-8145785
>
> --- a/test/java/awt/Toolkit/GetSizeTest/GetScreenSizeTest.java
> +++ b/test/java/awt/Toolkit/GetSizeTest/GetScreenSizeTest.java
> @@ -23,12 +23,12 @@
>
>   /*
>     @test
> -  @bug 8144074
> +  @bug 8144074 8145785
>     @summary Crash while getting screen size during Toolkit initialisation
> -  @run main/othervm GetScreenSize
> +  @run main/othervm GetScreenSizeTest
>   */
>
> -public class GetScreenSize {
> +public class GetScreenSizeTest {
>       public static void main(String[] args) {
>           java.awt.Toolkit.getDefaultToolkit().getScreenSize();
>       }
>


-- 
Best regards, Sergey.


From alin_craciunescu at yahoo.com  Sat Dec 19 00:09:04 2015
From: alin_craciunescu at yahoo.com (Alin Craciunescu)
Date: Sat, 19 Dec 2015 00:09:04 +0000 (UTC)
Subject: [OpenJDK 2D-Dev] OpenJDK, IcedTea security settings
References: <336770243.756394.1450483744191.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <336770243.756394.1450483744191.JavaMail.yahoo@mail.yahoo.com>

Hi,
Can you answer please to these questions?
?If you would like to answer, you can chose one of the forums:
OpenJDK, IcedTea security settings

| ? |
| ? |  | ? | ? | ? | ? | ? |
| OpenJDK, IcedTea security settingsI am a beginner Linux user. From my knowledge the system uses OpenJDK and IcedTea only when I connect to a SAP IDES s... |
|  |
| View on askub... | Preview by Yahoo |
|  |
| ? |


OpenJDK and IcedTea security settings

| ? |
| ? | ? | ? | ? | ? |
| OpenJDK and IcedTea security settingsI am a beginner Linux user. From my knowledge the system uses OpenJDK and IcedTea only when I connect to a SAP IDES server through SAP GUI JAVA adding a string in it to connect to that server. I use SAP for m... |
|  |
| View on ubuntuforums.org | Preview by Yahoo |
|  |
| ? |


Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151219/f1c5b7e5/attachment.html>

From philip.race at oracle.com  Tue Dec 22 19:53:14 2015
From: philip.race at oracle.com (Phil Race)
Date: Tue, 22 Dec 2015 11:53:14 -0800
Subject: [OpenJDK 2D-Dev] Result: New 2d Group Member: Sergey Bylokhov
Message-ID: <5679AA2A.9040908@oracle.com>

The vote for Sergey Bylokhov [1] is now closed.

Yes: 4
Veto: 0
Abstain: 0

According to the OpenJDK Bylaws definition of Lazy Consensus [2],
this is sufficient to approve the nomination.

-phil.

[1] http://mail.openjdk.java.net/pipermail/2d-dev/2015-December/006011.html
[2] http://openjdk.java.net/bylaws#lazy-consensus


From philip.race at oracle.com  Wed Dec 23 21:55:02 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 23 Dec 2015 13:55:02 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8145808: [PIT] test
	java/awt/Graphics2D/MTGraphicsAccessTest
Message-ID: <567B1836.5080607@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8145808
http://cr.openjdk.java.net/~prr/8145808/

I believe we have a test bug where the decrement on the
counter is being treated as atomic but it is carried out on
different threads protected only by 'volatile'.

This fix does seem likely to make the test more reliable.
Note that "numexceptions" technically has the same issue
but it does not matter as it is mainly informational but
and any number > 0 is all that ever matters.
So I left that alone.

-phil.


From james.graham at oracle.com  Thu Dec 24 01:22:39 2015
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 23 Dec 2015 17:22:39 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8145808: [PIT] test
 java/awt/Graphics2D/MTGraphicsAccessTest
In-Reply-To: <567B1836.5080607@oracle.com>
References: <567B1836.5080607@oracle.com>
Message-ID: <567B48DF.2050207@oracle.com>

Looks good.

You're correct that volatile isn't enough to protect the case where 2 
threads finish their work at exactly the same time.  They would need a 
synchronized block around the decrements (the increments are executed in 
the constructor by the main thread so they aren't contended, but it 
couldn't hurt to have all of the counts be atomic)...

			...jim

On 12/23/2015 1:55 PM, Phil Race wrote:
> https://bugs.openjdk.java.net/browse/JDK-8145808
> http://cr.openjdk.java.net/~prr/8145808/
>
> I believe we have a test bug where the decrement on the
> counter is being treated as atomic but it is carried out on
> different threads protected only by 'volatile'.
>
> This fix does seem likely to make the test more reliable.
> Note that "numexceptions" technically has the same issue
> but it does not matter as it is mainly informational but
> and any number > 0 is all that ever matters.
> So I left that alone.
>
> -phil.


From Sergey.Bylokhov at oracle.com  Thu Dec 24 15:59:31 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 24 Dec 2015 18:59:31 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8145808: [PIT] test
 java/awt/Graphics2D/MTGraphicsAccessTest
In-Reply-To: <567B48DF.2050207@oracle.com>
References: <567B1836.5080607@oracle.com> <567B48DF.2050207@oracle.com>
Message-ID: <567C1663.1080704@oracle.com>

On 24/12/15 04:22, Jim Graham wrote:
> Looks good.

+1

>
> You're correct that volatile isn't enough to protect the case where 2
> threads finish their work at exactly the same time.  They would need a
> synchronized block around the decrements (the increments are executed in
> the constructor by the main thread so they aren't contended, but it
> couldn't hurt to have all of the counts be atomic)...
>
>              ...jim
>
> On 12/23/2015 1:55 PM, Phil Race wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8145808
>> http://cr.openjdk.java.net/~prr/8145808/
>>
>> I believe we have a test bug where the decrement on the
>> counter is being treated as atomic but it is carried out on
>> different threads protected only by 'volatile'.
>>
>> This fix does seem likely to make the test more reliable.
>> Note that "numexceptions" technically has the same issue
>> but it does not matter as it is mainly informational but
>> and any number > 0 is all that ever matters.
>> So I left that alone.
>>
>> -phil.


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Thu Dec 24 16:15:36 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 24 Dec 2015 19:15:36 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8145584:
 java/awt/font/TextLayout/TestGetPixelBounds.java fails on Linux
In-Reply-To: <5671D3A5.2000009@oracle.com>
References: <5671D3A5.2000009@oracle.com>
Message-ID: <567C1A28.8050200@oracle.com>

Hi, Phil.
I see that this test relies on some parameters(coords, text, rotate, 
underline, graphic) of the main, and skips some checks by default. 
Probably they should be covered by default as well via @run tag for example?

On 17/12/15 00:12, Phil Race wrote:
> http://cr.openjdk.java.net/~prr/8145584/
> https://bugs.openjdk.java.net/browse/JDK-8145584
>
> The bug is that the code that tries to measure where the bounds
> of the rendering is not applying the same  rounding of the rendering
> position as the rendering path does. It seems this test was just
> waiting for the right circumstances to come along to expose the bug.
>
> The test that fails was closed but I have determined we are OK to open it.
>
> -phil.


-- 
Best regards, Sergey.


From philip.race at oracle.com  Thu Dec 24 21:04:53 2015
From: philip.race at oracle.com (Phil Race)
Date: Thu, 24 Dec 2015 13:04:53 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8145584:
 java/awt/font/TextLayout/TestGetPixelBounds.java fails on Linux
In-Reply-To: <567C1A28.8050200@oracle.com>
References: <5671D3A5.2000009@oracle.com> <567C1A28.8050200@oracle.com>
Message-ID: <567C5DF5.4070104@oracle.com>

Hi,

So the issue there is that this seems to uncover that the rotate case is
buggy for TextLayout. I do not know why but it is incorrect in 8ux not 
just 9
and by a clear margin. I think I would prefer to take my (derived) test
case that shows this and file a separate bug. It must be wholly unrelated to
the reason for the failure I am fixing here.

-phil.

On 12/24/2015 08:15 AM, Sergey Bylokhov wrote:
> Hi, Phil.
> I see that this test relies on some parameters(coords, text, rotate, 
> underline, graphic) of the main, and skips some checks by default. 
> Probably they should be covered by default as well via @run tag for 
> example?
>
> On 17/12/15 00:12, Phil Race wrote:
>> http://cr.openjdk.java.net/~prr/8145584/
>> https://bugs.openjdk.java.net/browse/JDK-8145584
>>
>> The bug is that the code that tries to measure where the bounds
>> of the rendering is not applying the same  rounding of the rendering
>> position as the rendering path does. It seems this test was just
>> waiting for the right circumstances to come along to expose the bug.
>>
>> The test that fails was closed but I have determined we are OK to 
>> open it.
>>
>> -phil.
>
>



From brian.burkhalter at oracle.com  Thu Dec 24 21:33:59 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 24 Dec 2015 13:33:59 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8145113: OutOfMemoryError when reading a 17KB
	corrupted TIFF image
Message-ID: <256D39A2-323D-484E-A79D-9C2A9C61EE93@oracle.com>

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8145113
Patch:	http://cr.openjdk.java.net/~bpb/8145113/webrev.00/

Summary:

Add some checks performed when reading an image file directory (IFD):

1. Ensure that the count of values in a field does not overflow an int.
2. Ensure that the size of field data does not overflow an int.
3. Ensure that sufficient pointers to and byte counts of data segments are present.

For the last case, this means that either a JPEG interchange offset is available (a byte count is not strictly needed in this case), or both strip/tile offsets and strip/tile byte counts are available.

Thanks,

Brian

From alexander.v.stepanov at oracle.com  Fri Dec 25 13:10:13 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Fri, 25 Dec 2015 16:10:13 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8145776: [TEST] add a test checking multipage
 tiff creation
Message-ID: <567D4035.2050803@oracle.com>

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~yan/8145776/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8145776

Just a single test added checking the correctness of multi-page TIFF 
image creation.

Thanks,
Alexander



From Sergey.Bylokhov at oracle.com  Fri Dec 25 14:42:31 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 25 Dec 2015 17:42:31 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8145584:
 java/awt/font/TextLayout/TestGetPixelBounds.java fails on Linux
In-Reply-To: <567C5DF5.4070104@oracle.com>
References: <5671D3A5.2000009@oracle.com> <567C1A28.8050200@oracle.com>
	<567C5DF5.4070104@oracle.com>
Message-ID: <567D55D7.3080704@oracle.com>

On 25/12/15 00:04, Phil Race wrote:
> Hi,
>
> So the issue there is that this seems to uncover that the rotate case is
> buggy for TextLayout. I do not know why but it is incorrect in 8ux not
> just 9
> and by a clear margin. I think I would prefer to take my (derived) test
> case that shows this and file a separate bug.

This fix looks fine then, note that this test checks other things 
optionally, probably in the fix for a new bug these checks can be 
enabled also.

It must be wholly
> unrelated to
> the reason for the failure I am fixing here.
>
> -phil.
>
> On 12/24/2015 08:15 AM, Sergey Bylokhov wrote:
>> Hi, Phil.
>> I see that this test relies on some parameters(coords, text, rotate,
>> underline, graphic) of the main, and skips some checks by default.
>> Probably they should be covered by default as well via @run tag for
>> example?
>>
>> On 17/12/15 00:12, Phil Race wrote:
>>> http://cr.openjdk.java.net/~prr/8145584/
>>> https://bugs.openjdk.java.net/browse/JDK-8145584
>>>
>>> The bug is that the code that tries to measure where the bounds
>>> of the rendering is not applying the same  rounding of the rendering
>>> position as the rendering path does. It seems this test was just
>>> waiting for the right circumstances to come along to expose the bug.
>>>
>>> The test that fails was closed but I have determined we are OK to
>>> open it.
>>>
>>> -phil.
>>
>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Dec 28 13:19:39 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 28 Dec 2015 16:19:39 +0300
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] RFR 8138838: docs cleanup for
	java.desktop
In-Reply-To: <562F8522.9020005@oracle.com>
References: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default>
	<560A6628.5010807@oracle.com>
	<CA+kOe0_RoiEvvquZ-5aJ401b1oePuDG+7vd0ufzgctpFhUfaLA@mail.gmail.com>
	<560C8970.50805@oracle.com>
	<CA+kOe0-YkE_886K0b_OY4G7kmunx9eTG0rxhaoVt8YKUsixFHA@mail.gmail.com>
	<560D199B.30708@oracle.com> <56125B1B.9070905@oracle.com>
	<56125BC7.102@oracle.com> <562F8522.9020005@oracle.com>
Message-ID: <568136EB.6050709@oracle.com>

I guess, if no objections were raised, we can push it? Otherwise we will 
w8 forever. Please double check the changes for some merge issues before 
the push.

On 27/10/15 17:07, Sergey Bylokhov wrote:
> I have checked the non-swing files in the patch [1], and it looks fine
> so far (my eyes=(((..). I think that someone on 2d alias should approve
> it also, or probably will request some other possible form of review,
> like package splitting.
>
> [1] http://cr.openjdk.java.net/~avstepan/8138838/jdk.patch
>
> On 05.10.15 14:15, Alexander Stepanov wrote:
>> Sorry; wrong subject...
>>
>> On 10/5/2015 2:12 PM, Alexander Stepanov wrote:
>>> Hello,
>>>
>>> Could you please review the fix for
>>> https://bugs.openjdk.java.net/browse/JDK-8138838
>>>
>>> Patch + webrev zipped + specdiff report:
>>> http://cr.openjdk.java.net/~avstepan/8138838
>>>
>>> Just some cosmetic changes for docs (<code>...</code> -> {@code ...}
>>> replacement) + some misprints fixed.
>>>
>>> Not sure if these changes are desired at all for now.
>>>
>>> Thanks,
>>> Alexander
>>>
>>> (Just in case, adding the prehistory and sending a copy to
>>> core-libs-dev).
>>>
>>>
>>>
>>> On 10/1/2015 2:31 PM, Alexander Stepanov wrote:
>>>> Hello Martin, Stuart,
>>>>
>>>> Thank you for the notes,
>>>>
>>>> Yes, the initial utility is quite ugly, I just tried to prepare it as
>>>> quickly as possible hoping that it covers the majority of "trivial"
>>>> replace cases. Yes, it does not process multi-line <code> inclusions.
>>>>
>>>> >  s = s.replace( "<CODE>", tag1);
>>>> >  s = s.replace( "<Code>", tag1);
>>>> >  s = s.replace("</CODE>", tag2);
>>>> >  s = s.replace("</Code>", tag2);
>>>>
>>>> - replaced with "s = ln.replaceAll("(?i)<code>",
>>>> "<code>").replaceAll("(?i)</code>", "</code>");"
>>>>
>>>> Unfortunately my Perl/lisp knowledge are zero :)
>>>>
>>>> > Should you publish your specdiff?  I guess not - it would be empty!
>>>> For now it contains a single fixed misprint diff, but there are a few
>>>> another misprints at the moment which I'd like to include in the
>>>> patch as well.
>>>>
>>>> So if you don't have objections, I'll delay for a several days and
>>>> then publish a final RFR (probably containing changes in some other
>>>> repos like jaxws, corba or jaxp) which would be more formal
>>>> (containing bug # and the final specdiff report).
>>>>
>>>> Thanks again,
>>>> Alexander
>>>>
>>>>
>>>> On 10/1/2015 9:54 AM, Martin Buchholz wrote:
>>>>> Hi s'marks,
>>>>> You probably don't need to absolutify paths.
>>>>> And you can easily handle multiple args.
>>>>>
>>>>> (just for fun!)
>>>>> Checks for javadoc comment; handles popular html entities; handles
>>>>> multiple lines; handles both tt and code:
>>>>>
>>>>> #!/bin/bash
>>>>> find "$@" -name '*.java' | \
>>>>>   xargs -r perl -p0777i -e \
>>>>>   'do {} while s~^
>>>>> *\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)</\1>~$_=$2;
>>>>> s/&lt;/</g; s/&gt;/>/g; s/&amp;/&/g; "{\@code $_}"~mgie'
>>>>>
>>>>>
>>>>> On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks
>>>>> <stuart.marks at oracle.com <mailto:stuart.marks at oracle.com>> wrote:
>>>>>
>>>>>     Hi Alexander, Martin,
>>>>>
>>>>>     The challenge of Perl file slurping and Emacs one-liners was too
>>>>>     much to bear.
>>>>>
>>>>>     This is Java, so one-liners are hardly possible. Still, there are
>>>>>     a bunch of improvements that can be made to the Java version. (OK,
>>>>>     and I'm showing off a bit.)
>>>>>
>>>>>     Take a look at this:
>>>>>
>>>>> http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java
>>>>> <http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java>
>>>>>
>>>>>
>>>>>     I haven't studied the output exhaustively, but it seems to do a
>>>>>     reasonably good job for the common cases. I ran it over java.lang
>>>>>     and I noticed a few cases where there is markup embedded within
>>>>>     <code></code> text, which should be looked at more closely.
>>>>>
>>>>>     I don't particularly care if you use my version, but there are
>>>>>     some techniques that I'd strongly recommend that you consider
>>>>>     using in any such tool. In particular:
>>>>>
>>>>>      - Pattern.DOTALL to do multi-line matches
>>>>>      - Pattern.CASE_INSENSITIVE
>>>>>      - try-with-resources to ensure that files are closed properly
>>>>>      - NIO instead of old java.io <http://java.io> APIs, particularly
>>>>>     Files.walk() and streams
>>>>>      - use Scanner to deal with input file buffering
>>>>>      - Scanner's stream support (I recently added this to JDK 9)
>>>>>
>>>>>     Enjoy,
>>>>>
>>>>>     s'marks
>>>>>
>>>>>
>>>>>
>>>>>     On 9/29/15 2:23 PM, Martin Buchholz wrote:
>>>>>
>>>>>         Hi Alexander,
>>>>>
>>>>>         your change looks good.  It's OK to have manual corrections
>>>>>         for automated
>>>>>         mega-changes like this, as long as they all revert changes.
>>>>>
>>>>>         Random comments:
>>>>>
>>>>>         Should you publish your specdiff?  I guess not - it would be
>>>>>         empty!
>>>>>
>>>>>                      while((s = br.readLine()) != null) {
>>>>>
>>>>>         by matching only one line at a time, you lose the ability to
>>>>> make
>>>>>         replacements that span lines.  Perlers like to "slurp" in the
>>>>>         entire file
>>>>>         as a single string.
>>>>>
>>>>>                  s = s.replace( "<CODE>", tag1);
>>>>>                  s = s.replace( "<Code>", tag1);
>>>>>                  s = s.replace("</CODE>", tag2);
>>>>>                  s = s.replace("</Code>", tag2);
>>>>>
>>>>>         Why not use case-insensitive regex?
>>>>>
>>>>>         Here's an emacs-lisp one-liner I've been known to use:
>>>>>
>>>>>         (defun tt-code ()
>>>>>            (interactive)
>>>>>            (query-replace-regexp
>>>>> "<\\(tt\\|code\\)>\\([^&<>\\\\]+\\)</\\1>" "{@code
>>>>>         \\2}"))
>>>>>
>>>>>         With more work, one can automate transformation of embedded
>>>>>         things like &lt;
>>>>>
>>>>>         But of course, it's not even possible to transform ALL uses of
>>>>>         <code> to
>>>>>         {@code, if there was imaginative use of nested html tags.
>>>>>
>>>>>
>>>>>         On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov <
>>>>>         alexander.v.stepanov at oracle.com
>>>>>         <mailto:alexander.v.stepanov at oracle.com>> wrote:
>>>>>
>>>>>             Updated: a few manual corrections were made (as @linkplain
>>>>>             tags displays
>>>>>             nested {@code } literally):
>>>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch
>>>>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch>
>>>>>             -checked with specdiff (which of course does not cover
>>>>>             documentation for
>>>>>             internal packages), no unexpected diffs detected.
>>>>>
>>>>>             Regards,
>>>>>             Alexander
>>>>>
>>>>>
>>>>>             On 9/27/2015 4:52 PM, Alexander Stepanov wrote:
>>>>>
>>>>>                 Hello Martin,
>>>>>
>>>>>                 Here is some simple app. to replace <code></code> tags
>>>>>                 with a new-style
>>>>>                 {@code } one (which is definitely not so elegant as
>>>>>                 the Perl one-liners):
>>>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java
>>>>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/SimpleTagEditor.java>
>>>>>
>>>>>
>>>>>
>>>>>                 Corresponding patch for jdk and replacement log (~62k
>>>>>                 of the tag changes):
>>>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch
>>>>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch>
>>>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log
>>>>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/replace.log>
>>>>>                 (sorry, I have to check the correctness of the patch
>>>>>                 with specdiff yet,
>>>>>                 so this is rather demo at the moment).
>>>>>
>>>>>                 Don't know if these changes (cosmetic by nature) are
>>>>>                 desired for now or
>>>>>                 not. Moreover, probably some part of them should go to
>>>>>                 another repos (e.g.,
>>>>>                 awt, swing -> "client" instead of "dev").
>>>>>
>>>>>                 Regards,
>>>>>                 Alexander
>>>>>
>>>>
>>>
>>
>
>


-- 
Best regards, Sergey.


From yuri.nesterenko at oracle.com  Mon Dec 28 13:35:06 2015
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Mon, 28 Dec 2015 16:35:06 +0300
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] RFR 8138838: docs cleanup for
 java.desktop
In-Reply-To: <568136EB.6050709@oracle.com>
References: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default>
	<560A6628.5010807@oracle.com>
	<CA+kOe0_RoiEvvquZ-5aJ401b1oePuDG+7vd0ufzgctpFhUfaLA@mail.gmail.com>
	<560C8970.50805@oracle.com>
	<CA+kOe0-YkE_886K0b_OY4G7kmunx9eTG0rxhaoVt8YKUsixFHA@mail.gmail.com>
	<560D199B.30708@oracle.com> <56125B1B.9070905@oracle.com>
	<56125BC7.102@oracle.com> <562F8522.9020005@oracle.com>
	<568136EB.6050709@oracle.com>
Message-ID: <56813A8A.3020601@oracle.com>

off list: I'm afraid it will be on Jan 11-th earliest.

-yan

On 12/28/2015 04:19 PM, Sergey Bylokhov wrote:
> I guess, if no objections were raised, we can push it? Otherwise we will
> w8 forever. Please double check the changes for some merge issues before
> the push.
>
> On 27/10/15 17:07, Sergey Bylokhov wrote:
>> I have checked the non-swing files in the patch [1], and it looks fine
>> so far (my eyes=(((..). I think that someone on 2d alias should approve
>> it also, or probably will request some other possible form of review,
>> like package splitting.
>>
>> [1] http://cr.openjdk.java.net/~avstepan/8138838/jdk.patch
>>
>> On 05.10.15 14:15, Alexander Stepanov wrote:
>>> Sorry; wrong subject...
>>>
>>> On 10/5/2015 2:12 PM, Alexander Stepanov wrote:
>>>> Hello,
>>>>
>>>> Could you please review the fix for
>>>> https://bugs.openjdk.java.net/browse/JDK-8138838
>>>>
>>>> Patch + webrev zipped + specdiff report:
>>>> http://cr.openjdk.java.net/~avstepan/8138838
>>>>
>>>> Just some cosmetic changes for docs (<code>...</code> -> {@code ...}
>>>> replacement) + some misprints fixed.
>>>>
>>>> Not sure if these changes are desired at all for now.
>>>>
>>>> Thanks,
>>>> Alexander
>>>>
>>>> (Just in case, adding the prehistory and sending a copy to
>>>> core-libs-dev).
>>>>
>>>>
>>>>
>>>> On 10/1/2015 2:31 PM, Alexander Stepanov wrote:
>>>>> Hello Martin, Stuart,
>>>>>
>>>>> Thank you for the notes,
>>>>>
>>>>> Yes, the initial utility is quite ugly, I just tried to prepare it as
>>>>> quickly as possible hoping that it covers the majority of "trivial"
>>>>> replace cases. Yes, it does not process multi-line <code> inclusions.
>>>>>
>>>>> >  s = s.replace( "<CODE>", tag1);
>>>>> >  s = s.replace( "<Code>", tag1);
>>>>> >  s = s.replace("</CODE>", tag2);
>>>>> >  s = s.replace("</Code>", tag2);
>>>>>
>>>>> - replaced with "s = ln.replaceAll("(?i)<code>",
>>>>> "<code>").replaceAll("(?i)</code>", "</code>");"
>>>>>
>>>>> Unfortunately my Perl/lisp knowledge are zero :)
>>>>>
>>>>> > Should you publish your specdiff?  I guess not - it would be empty!
>>>>> For now it contains a single fixed misprint diff, but there are a few
>>>>> another misprints at the moment which I'd like to include in the
>>>>> patch as well.
>>>>>
>>>>> So if you don't have objections, I'll delay for a several days and
>>>>> then publish a final RFR (probably containing changes in some other
>>>>> repos like jaxws, corba or jaxp) which would be more formal
>>>>> (containing bug # and the final specdiff report).
>>>>>
>>>>> Thanks again,
>>>>> Alexander
>>>>>
>>>>>
>>>>> On 10/1/2015 9:54 AM, Martin Buchholz wrote:
>>>>>> Hi s'marks,
>>>>>> You probably don't need to absolutify paths.
>>>>>> And you can easily handle multiple args.
>>>>>>
>>>>>> (just for fun!)
>>>>>> Checks for javadoc comment; handles popular html entities; handles
>>>>>> multiple lines; handles both tt and code:
>>>>>>
>>>>>> #!/bin/bash
>>>>>> find "$@" -name '*.java' | \
>>>>>>   xargs -r perl -p0777i -e \
>>>>>>   'do {} while s~^
>>>>>> *\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)</\1>~$_=$2;
>>>>>> s/&lt;/</g; s/&gt;/>/g; s/&amp;/&/g; "{\@code $_}"~mgie'
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks
>>>>>> <stuart.marks at oracle.com <mailto:stuart.marks at oracle.com>> wrote:
>>>>>>
>>>>>>     Hi Alexander, Martin,
>>>>>>
>>>>>>     The challenge of Perl file slurping and Emacs one-liners was too
>>>>>>     much to bear.
>>>>>>
>>>>>>     This is Java, so one-liners are hardly possible. Still, there are
>>>>>>     a bunch of improvements that can be made to the Java version.
>>>>>> (OK,
>>>>>>     and I'm showing off a bit.)
>>>>>>
>>>>>>     Take a look at this:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java
>>>>>> <http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java>
>>>>>>
>>>>>>
>>>>>>
>>>>>>     I haven't studied the output exhaustively, but it seems to do a
>>>>>>     reasonably good job for the common cases. I ran it over java.lang
>>>>>>     and I noticed a few cases where there is markup embedded within
>>>>>>     <code></code> text, which should be looked at more closely.
>>>>>>
>>>>>>     I don't particularly care if you use my version, but there are
>>>>>>     some techniques that I'd strongly recommend that you consider
>>>>>>     using in any such tool. In particular:
>>>>>>
>>>>>>      - Pattern.DOTALL to do multi-line matches
>>>>>>      - Pattern.CASE_INSENSITIVE
>>>>>>      - try-with-resources to ensure that files are closed properly
>>>>>>      - NIO instead of old java.io <http://java.io> APIs, particularly
>>>>>>     Files.walk() and streams
>>>>>>      - use Scanner to deal with input file buffering
>>>>>>      - Scanner's stream support (I recently added this to JDK 9)
>>>>>>
>>>>>>     Enjoy,
>>>>>>
>>>>>>     s'marks
>>>>>>
>>>>>>
>>>>>>
>>>>>>     On 9/29/15 2:23 PM, Martin Buchholz wrote:
>>>>>>
>>>>>>         Hi Alexander,
>>>>>>
>>>>>>         your change looks good.  It's OK to have manual corrections
>>>>>>         for automated
>>>>>>         mega-changes like this, as long as they all revert changes.
>>>>>>
>>>>>>         Random comments:
>>>>>>
>>>>>>         Should you publish your specdiff?  I guess not - it would be
>>>>>>         empty!
>>>>>>
>>>>>>                      while((s = br.readLine()) != null) {
>>>>>>
>>>>>>         by matching only one line at a time, you lose the ability to
>>>>>> make
>>>>>>         replacements that span lines.  Perlers like to "slurp" in the
>>>>>>         entire file
>>>>>>         as a single string.
>>>>>>
>>>>>>                  s = s.replace( "<CODE>", tag1);
>>>>>>                  s = s.replace( "<Code>", tag1);
>>>>>>                  s = s.replace("</CODE>", tag2);
>>>>>>                  s = s.replace("</Code>", tag2);
>>>>>>
>>>>>>         Why not use case-insensitive regex?
>>>>>>
>>>>>>         Here's an emacs-lisp one-liner I've been known to use:
>>>>>>
>>>>>>         (defun tt-code ()
>>>>>>            (interactive)
>>>>>>            (query-replace-regexp
>>>>>> "<\\(tt\\|code\\)>\\([^&<>\\\\]+\\)</\\1>" "{@code
>>>>>>         \\2}"))
>>>>>>
>>>>>>         With more work, one can automate transformation of embedded
>>>>>>         things like &lt;
>>>>>>
>>>>>>         But of course, it's not even possible to transform ALL
>>>>>> uses of
>>>>>>         <code> to
>>>>>>         {@code, if there was imaginative use of nested html tags.
>>>>>>
>>>>>>
>>>>>>         On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov <
>>>>>>         alexander.v.stepanov at oracle.com
>>>>>>         <mailto:alexander.v.stepanov at oracle.com>> wrote:
>>>>>>
>>>>>>             Updated: a few manual corrections were made (as
>>>>>> @linkplain
>>>>>>             tags displays
>>>>>>             nested {@code } literally):
>>>>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch
>>>>>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch>
>>>>>>             -checked with specdiff (which of course does not cover
>>>>>>             documentation for
>>>>>>             internal packages), no unexpected diffs detected.
>>>>>>
>>>>>>             Regards,
>>>>>>             Alexander
>>>>>>
>>>>>>
>>>>>>             On 9/27/2015 4:52 PM, Alexander Stepanov wrote:
>>>>>>
>>>>>>                 Hello Martin,
>>>>>>
>>>>>>                 Here is some simple app. to replace <code></code>
>>>>>> tags
>>>>>>                 with a new-style
>>>>>>                 {@code } one (which is definitely not so elegant as
>>>>>>                 the Perl one-liners):
>>>>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java
>>>>>>
>>>>>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/SimpleTagEditor.java>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                 Corresponding patch for jdk and replacement log (~62k
>>>>>>                 of the tag changes):
>>>>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch
>>>>>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch>
>>>>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log
>>>>>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/replace.log>
>>>>>>                 (sorry, I have to check the correctness of the patch
>>>>>>                 with specdiff yet,
>>>>>>                 so this is rather demo at the moment).
>>>>>>
>>>>>>                 Don't know if these changes (cosmetic by nature) are
>>>>>>                 desired for now or
>>>>>>                 not. Moreover, probably some part of them should
>>>>>> go to
>>>>>>                 another repos (e.g.,
>>>>>>                 awt, swing -> "client" instead of "dev").
>>>>>>
>>>>>>                 Regards,
>>>>>>                 Alexander
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>



From alexander.v.stepanov at oracle.com  Mon Dec 28 21:59:00 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Tue, 29 Dec 2015 00:59:00 +0300
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] RFR 8138838: docs cleanup for
	java.desktop
In-Reply-To: <568136EB.6050709@oracle.com>
References: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default>
	<560A6628.5010807@oracle.com>
	<CA+kOe0_RoiEvvquZ-5aJ401b1oePuDG+7vd0ufzgctpFhUfaLA@mail.gmail.com>
	<560C8970.50805@oracle.com>
	<CA+kOe0-YkE_886K0b_OY4G7kmunx9eTG0rxhaoVt8YKUsixFHA@mail.gmail.com>
	<560D199B.30708@oracle.com> <56125B1B.9070905@oracle.com>
	<56125BC7.102@oracle.com> <562F8522.9020005@oracle.com>
	<568136EB.6050709@oracle.com>
Message-ID: <5681B0A4.1020705@oracle.com>

Hello Sergey,

 > I guess, if no objections were raised, we can push it? Otherwise we 
will w8 forever. Please double check the changes for some merge issues 
before the push.

Unfortunately I have some issues with my ssh key. At least I cannot 
publish my webrevs at cr, so probably I can't push as well (and I don't 
like putting anyone to trouble asking to push these massive changes).

Just in case (to save the thread), the latest version of the patch 
(which does not affect swing part) is here:
http://cr.openjdk.java.net/~avstepan/8138838/noSwing/jdk.patch
(please see 
http://mail.openjdk.java.net/pipermail/awt-dev/2015-November/010277.html)
and it could be integrated without conflicts into the current version of 
client (checked just now).

Thanks,
Alexander


On 12/28/2015 4:19 PM, Sergey Bylokhov wrote:
> I guess, if no objections were raised, we can push it? Otherwise we 
> will w8 forever. Please double check the changes for some merge issues 
> before the push.
>
> On 27/10/15 17:07, Sergey Bylokhov wrote:
>> I have checked the non-swing files in the patch [1], and it looks fine
>> so far (my eyes=(((..). I think that someone on 2d alias should approve
>> it also, or probably will request some other possible form of review,
>> like package splitting.
>>
>> [1] http://cr.openjdk.java.net/~avstepan/8138838/jdk.patch
>>
>> On 05.10.15 14:15, Alexander Stepanov wrote:
>>> Sorry; wrong subject...
>>>
>>> On 10/5/2015 2:12 PM, Alexander Stepanov wrote:
>>>> Hello,
>>>>
>>>> Could you please review the fix for
>>>> https://bugs.openjdk.java.net/browse/JDK-8138838
>>>>
>>>> Patch + webrev zipped + specdiff report:
>>>> http://cr.openjdk.java.net/~avstepan/8138838
>>>>
>>>> Just some cosmetic changes for docs (<code>...</code> -> {@code ...}
>>>> replacement) + some misprints fixed.
>>>>
>>>> Not sure if these changes are desired at all for now.
>>>>
>>>> Thanks,
>>>> Alexander
>>>>
>>>> (Just in case, adding the prehistory and sending a copy to
>>>> core-libs-dev).
>>>>
>>>>
>>>>
>>>> On 10/1/2015 2:31 PM, Alexander Stepanov wrote:
>>>>> Hello Martin, Stuart,
>>>>>
>>>>> Thank you for the notes,
>>>>>
>>>>> Yes, the initial utility is quite ugly, I just tried to prepare it as
>>>>> quickly as possible hoping that it covers the majority of "trivial"
>>>>> replace cases. Yes, it does not process multi-line <code> inclusions.
>>>>>
>>>>> >  s = s.replace( "<CODE>", tag1);
>>>>> >  s = s.replace( "<Code>", tag1);
>>>>> >  s = s.replace("</CODE>", tag2);
>>>>> >  s = s.replace("</Code>", tag2);
>>>>>
>>>>> - replaced with "s = ln.replaceAll("(?i)<code>",
>>>>> "<code>").replaceAll("(?i)</code>", "</code>");"
>>>>>
>>>>> Unfortunately my Perl/lisp knowledge are zero :)
>>>>>
>>>>> > Should you publish your specdiff?  I guess not - it would be empty!
>>>>> For now it contains a single fixed misprint diff, but there are a few
>>>>> another misprints at the moment which I'd like to include in the
>>>>> patch as well.
>>>>>
>>>>> So if you don't have objections, I'll delay for a several days and
>>>>> then publish a final RFR (probably containing changes in some other
>>>>> repos like jaxws, corba or jaxp) which would be more formal
>>>>> (containing bug # and the final specdiff report).
>>>>>
>>>>> Thanks again,
>>>>> Alexander
>>>>>
>>>>>
>>>>> On 10/1/2015 9:54 AM, Martin Buchholz wrote:
>>>>>> Hi s'marks,
>>>>>> You probably don't need to absolutify paths.
>>>>>> And you can easily handle multiple args.
>>>>>>
>>>>>> (just for fun!)
>>>>>> Checks for javadoc comment; handles popular html entities; handles
>>>>>> multiple lines; handles both tt and code:
>>>>>>
>>>>>> #!/bin/bash
>>>>>> find "$@" -name '*.java' | \
>>>>>>   xargs -r perl -p0777i -e \
>>>>>>   'do {} while s~^
>>>>>> *\*.*\K<(tt|code)>((?:[^<>{}\&\@]|&(?:lt|gt|amp);)*)</\1>~$_=$2;
>>>>>> s/&lt;/</g; s/&gt;/>/g; s/&amp;/&/g; "{\@code $_}"~mgie'
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 30, 2015 at 6:16 PM, Stuart Marks
>>>>>> <stuart.marks at oracle.com <mailto:stuart.marks at oracle.com>> wrote:
>>>>>>
>>>>>>     Hi Alexander, Martin,
>>>>>>
>>>>>>     The challenge of Perl file slurping and Emacs one-liners was too
>>>>>>     much to bear.
>>>>>>
>>>>>>     This is Java, so one-liners are hardly possible. Still, there 
>>>>>> are
>>>>>>     a bunch of improvements that can be made to the Java version. 
>>>>>> (OK,
>>>>>>     and I'm showing off a bit.)
>>>>>>
>>>>>>     Take a look at this:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~smarks/misc/SimpleTagEditorSmarks1.java
>>>>>> <http://cr.openjdk.java.net/%7Esmarks/misc/SimpleTagEditorSmarks1.java> 
>>>>>>
>>>>>>
>>>>>>
>>>>>>     I haven't studied the output exhaustively, but it seems to do a
>>>>>>     reasonably good job for the common cases. I ran it over 
>>>>>> java.lang
>>>>>>     and I noticed a few cases where there is markup embedded within
>>>>>>     <code></code> text, which should be looked at more closely.
>>>>>>
>>>>>>     I don't particularly care if you use my version, but there are
>>>>>>     some techniques that I'd strongly recommend that you consider
>>>>>>     using in any such tool. In particular:
>>>>>>
>>>>>>      - Pattern.DOTALL to do multi-line matches
>>>>>>      - Pattern.CASE_INSENSITIVE
>>>>>>      - try-with-resources to ensure that files are closed properly
>>>>>>      - NIO instead of old java.io <http://java.io> APIs, 
>>>>>> particularly
>>>>>>     Files.walk() and streams
>>>>>>      - use Scanner to deal with input file buffering
>>>>>>      - Scanner's stream support (I recently added this to JDK 9)
>>>>>>
>>>>>>     Enjoy,
>>>>>>
>>>>>>     s'marks
>>>>>>
>>>>>>
>>>>>>
>>>>>>     On 9/29/15 2:23 PM, Martin Buchholz wrote:
>>>>>>
>>>>>>         Hi Alexander,
>>>>>>
>>>>>>         your change looks good.  It's OK to have manual corrections
>>>>>>         for automated
>>>>>>         mega-changes like this, as long as they all revert changes.
>>>>>>
>>>>>>         Random comments:
>>>>>>
>>>>>>         Should you publish your specdiff?  I guess not - it would be
>>>>>>         empty!
>>>>>>
>>>>>>                      while((s = br.readLine()) != null) {
>>>>>>
>>>>>>         by matching only one line at a time, you lose the ability to
>>>>>> make
>>>>>>         replacements that span lines.  Perlers like to "slurp" in 
>>>>>> the
>>>>>>         entire file
>>>>>>         as a single string.
>>>>>>
>>>>>>                  s = s.replace( "<CODE>", tag1);
>>>>>>                  s = s.replace( "<Code>", tag1);
>>>>>>                  s = s.replace("</CODE>", tag2);
>>>>>>                  s = s.replace("</Code>", tag2);
>>>>>>
>>>>>>         Why not use case-insensitive regex?
>>>>>>
>>>>>>         Here's an emacs-lisp one-liner I've been known to use:
>>>>>>
>>>>>>         (defun tt-code ()
>>>>>>            (interactive)
>>>>>>            (query-replace-regexp
>>>>>> "<\\(tt\\|code\\)>\\([^&<>\\\\]+\\)</\\1>" "{@code
>>>>>>         \\2}"))
>>>>>>
>>>>>>         With more work, one can automate transformation of embedded
>>>>>>         things like &lt;
>>>>>>
>>>>>>         But of course, it's not even possible to transform ALL 
>>>>>> uses of
>>>>>>         <code> to
>>>>>>         {@code, if there was imaginative use of nested html tags.
>>>>>>
>>>>>>
>>>>>>         On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov <
>>>>>>         alexander.v.stepanov at oracle.com
>>>>>> <mailto:alexander.v.stepanov at oracle.com>> wrote:
>>>>>>
>>>>>>             Updated: a few manual corrections were made (as 
>>>>>> @linkplain
>>>>>>             tags displays
>>>>>>             nested {@code } literally):
>>>>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch
>>>>>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch>
>>>>>>             -checked with specdiff (which of course does not cover
>>>>>>             documentation for
>>>>>>             internal packages), no unexpected diffs detected.
>>>>>>
>>>>>>             Regards,
>>>>>>             Alexander
>>>>>>
>>>>>>
>>>>>>             On 9/27/2015 4:52 PM, Alexander Stepanov wrote:
>>>>>>
>>>>>>                 Hello Martin,
>>>>>>
>>>>>>                 Here is some simple app. to replace <code></code> 
>>>>>> tags
>>>>>>                 with a new-style
>>>>>>                 {@code } one (which is definitely not so elegant as
>>>>>>                 the Perl one-liners):
>>>>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java 
>>>>>>
>>>>>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/SimpleTagEditor.java> 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                 Corresponding patch for jdk and replacement log 
>>>>>> (~62k
>>>>>>                 of the tag changes):
>>>>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch
>>>>>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/jdk.patch>
>>>>>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log
>>>>>> <http://cr.openjdk.java.net/%7Eavstepan/tmp/codeTags/replace.log>
>>>>>>                 (sorry, I have to check the correctness of the patch
>>>>>>                 with specdiff yet,
>>>>>>                 so this is rather demo at the moment).
>>>>>>
>>>>>>                 Don't know if these changes (cosmetic by nature) are
>>>>>>                 desired for now or
>>>>>>                 not. Moreover, probably some part of them should 
>>>>>> go to
>>>>>>                 another repos (e.g.,
>>>>>>                 awt, swing -> "client" instead of "dev").
>>>>>>
>>>>>>                 Regards,
>>>>>>                 Alexander
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>



From brian.burkhalter at oracle.com  Mon Dec 28 23:12:41 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 28 Dec 2015 15:12:41 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8145776: [TEST] add a test checking
	multipage tiff creation
In-Reply-To: <567D4035.2050803@oracle.com>
References: <567D4035.2050803@oracle.com>
Message-ID: <AB0EB362-6C43-4DBD-BE9A-D5D96CC478D2@oracle.com>

Hello Alexander,

A few comments.

1) Lines 53,59: By convention it is better to put constants in upper case, e.g., NUM_IMAGES and BLACK_SIZE.

2) Line 45, 102: The test references the internal package com.sun.imageio.plugins.tiff. In general it is better to use the public packages.

3) Line 69: If the test fails, it would be good to know the random seed. It would also be good to be able to set the seed when running the test. The approach taken in core libraries may be seen in test/java/math/BigInteger/BigIntegerTest.java. The jdk.testlibrary.RandomFactory class is used to create the Random instance and to obtain any seed provided via Java properties. This requires the test tags ?@library /lib/testlibrary? and ?@build jdk.testlibrary.*? and it is also good to add ?@key randomness.? 

Regards,

Brian

On Dec 25, 2015, at 5:10 AM, Alexander Stepanov <alexander.v.stepanov at oracle.com> wrote:

> Could you please review the following fix
> http://cr.openjdk.java.net/~yan/8145776/webrev.00/
> for
> https://bugs.openjdk.java.net/browse/JDK-8145776
> 
> Just a single test added checking the correctness of multi-page TIFF image creation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151228/5e69023a/attachment.html>

From alexander.v.stepanov at oracle.com  Tue Dec 29 12:44:34 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Tue, 29 Dec 2015 15:44:34 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8145776: [TEST] add a test checking
 multipage tiff creation
In-Reply-To: <AB0EB362-6C43-4DBD-BE9A-D5D96CC478D2@oracle.com>
References: <567D4035.2050803@oracle.com>
	<AB0EB362-6C43-4DBD-BE9A-D5D96CC478D2@oracle.com>
Message-ID: <56828032.3040304@oracle.com>

Hello Brian,

Thank you for the notes, please see the updated webrev:
http://cr.openjdk.java.net/~yan/8145776/webrev.01/

1., 3. - fixed
WRT 2.: this import is necessary to use TIFFImageWriter, 
TIFFImageWriterSpi. As it follows from 
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/07ae3247e988, the majority 
of new classes (excepting tag sets) were added to 
com.sun.imageio.plugins.tiff. Do you mean these classes would be moved 
to javax/imageio soon? (please note also a @module tag added for 
compatibility with modular java).

Thanks,
Alexander

On 12/29/2015 2:12 AM, Brian Burkhalter wrote:
> Hello Alexander,
>
> A few comments.
>
> 1) Lines 53,59: By convention it is better to put constants in upper 
> case, e.g., NUM_IMAGES and BLACK_SIZE.
>
> 2) Line 45, 102: The test references the internal package 
> com.sun.imageio.plugins.tiff. In general it is better to use the 
> public packages.
>
> 3) Line 69: If the test fails, it would be good to know the random 
> seed. It would also be good to be able to set the seed when running 
> the test. The approach taken in core libraries may be seen in 
> test/java/math/BigInteger/BigIntegerTest.java. The 
> jdk.testlibrary.RandomFactory class is used to create the Random 
> instance and to obtain any seed provided via Java properties. This 
> requires the test tags ?@library /lib/testlibrary? and ?@build 
> jdk.testlibrary.*? and it is also good to add ?@key randomness.?
>
> Regards,
>
> Brian
>
> On Dec 25, 2015, at 5:10 AM, Alexander Stepanov 
> <alexander.v.stepanov at oracle.com 
> <mailto:alexander.v.stepanov at oracle.com>> wrote:
>
>> Could you please review the following fix
>> http://cr.openjdk.java.net/~yan/8145776/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Eyan/8145776/webrev.00/>
>> for
>> https://bugs.openjdk.java.net/browse/JDK-8145776
>>
>> Just a single test added checking the correctness of multi-page TIFF 
>> image creation.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151229/ddebca5a/attachment.html>

From brian.burkhalter at oracle.com  Tue Dec 29 18:20:38 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 29 Dec 2015 10:20:38 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8145776: [TEST] add a test checking
	multipage tiff creation
In-Reply-To: <56828032.3040304@oracle.com>
References: <567D4035.2050803@oracle.com>
	<AB0EB362-6C43-4DBD-BE9A-D5D96CC478D2@oracle.com>
	<56828032.3040304@oracle.com>
Message-ID: <10E6296E-4E46-491A-AA45-637C4806B172@oracle.com>

Hello Alexander,

On Dec 29, 2015, at 4:44 AM, Alexander Stepanov <alexander.v.stepanov at oracle.com> wrote:

> Thank you for the notes, please see the updated webrev:
> http://cr.openjdk.java.net/~yan/8145776/webrev.01/
> 
> 1., 3. - fixed

This looks fine (but you still need approval from an actual Reviewer).

> WRT 2.: this import is necessary to use TIFFImageWriter, TIFFImageWriterSpi. As it follows fromhttp://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/07ae3247e988, the majority of new classes (excepting tag sets) were added to com.sun.imageio.plugins.tiff. Do you mean these classes would be moved to javax/imageio soon?

There is no intention to move any of the added com.sun classes to the javax namespace.

Also, if it is common practice to refer to com.sun classes in the tests, then my comments about referring only to classes in the public namespace (java.*, javax.*) may be disregarded.

> (please note also a @module tag added for compatibility with modular java).

Yes, I saw that.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151229/e769f09b/attachment.html>

From alexey.ushakov at jetbrains.com  Tue Dec 29 21:26:21 2015
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Wed, 30 Dec 2015 00:26:21 +0300
Subject: [OpenJDK 2D-Dev] Review request for: JDK-8146238 Java2D Queue
	Flusher crash on OSX after switching between user accounts
Message-ID: <D0922FAE-79D7-43FF-B37B-47FAA1108028@jetbrains.com>

Hello,
Here is the fix for openjdk9 of the crash in OGL pipeline on OSX , please have a look. The problem is also reproducible in JDK7 and JDK8
Bug : https://bugs.openjdk.java.net/browse/JDK-8146238
Webrev : http://cr.openjdk.java.net/~avu/JDK-8146238/webrev.00/
 
Issue : jdk crashes in Java2D Queue Flusher after minimising/maximising heavy swing app (IntelliJ IDEA for example) and changing user account, see the bug for more details

Root cause : CGLSurfaceData native data requires CGLGraphicsConfig native data for deallocation, however after disposing appropriate java objects (CGLGraphicsConfig and CGLSurfaceData) CGLGraphicsConfig native data might be deallocated before appropriate CGLSurfaceData native data, so deallocating latter causes crash

Solution : Added reference counting for CGLGraphicsConfig native data in order to dispose it after all native pointers for CGLSurfaceData objects

Best Regards,
Alexey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151230/78ad5942/attachment.html>

From alexander.v.stepanov at oracle.com  Tue Dec 29 22:31:12 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Wed, 30 Dec 2015 01:31:12 +0300
Subject: [OpenJDK 2D-Dev] RFR: 8145776: [TEST] add a test checking
 multipage tiff creation
In-Reply-To: <10E6296E-4E46-491A-AA45-637C4806B172@oracle.com>
References: <567D4035.2050803@oracle.com>
	<AB0EB362-6C43-4DBD-BE9A-D5D96CC478D2@oracle.com>
	<56828032.3040304@oracle.com>
	<10E6296E-4E46-491A-AA45-637C4806B172@oracle.com>
Message-ID: <568309B0.70405@oracle.com>

Hello Brian,

Thank you.

 > Also, if it is common practice to refer to com.sun classes in the tests

It seems there are a lot of tests in jdk/test referring to the internal 
packages, but I'm not sure if it is a conventional or legacy practice.

Thanks,
Alexander

On 12/29/2015 9:20 PM, Brian Burkhalter wrote:
> Hello Alexander,
>
> On Dec 29, 2015, at 4:44 AM, Alexander Stepanov 
> <alexander.v.stepanov at oracle.com 
> <mailto:alexander.v.stepanov at oracle.com>> wrote:
>
>> Thank you for the notes, please see the updated webrev:
>> http://cr.openjdk.java.net/~yan/8145776/webrev.01/
>>
>> 1., 3. - fixed
>
> This looks fine (but you still need approval from an actual Reviewer).
>
>> WRT 2.: this import is necessary to use TIFFImageWriter, 
>> TIFFImageWriterSpi. As it follows 
>> fromhttp://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/07ae3247e988, the 
>> majority of new classes (excepting tag sets) were added to 
>> com.sun.imageio.plugins.tiff. Do you mean these classes would be 
>> moved to javax/imageio soon?
>
> There is no intention to move any of the added com.sun classes to the 
> javax namespace.
>
> Also, if it is common practice to refer to com.sun classes in the 
> tests, then my comments about referring only to classes in the public 
> namespace (java.*, javax.*) may be disregarded.
>
>> (please note also a @module tag added for compatibility with modular 
>> java).
>
> Yes, I saw that.
>
> Thanks,
>
> Brian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151230/e220669c/attachment.html>

From Sergey.Bylokhov at oracle.com  Wed Dec 30 14:34:48 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 30 Dec 2015 17:34:48 +0300
Subject: [OpenJDK 2D-Dev] Review request for: JDK-8146238 Java2D Queue
 Flusher crash on OSX after switching between user accounts
In-Reply-To: <D0922FAE-79D7-43FF-B37B-47FAA1108028@jetbrains.com>
References: <D0922FAE-79D7-43FF-B37B-47FAA1108028@jetbrains.com>
Message-ID: <5683EB88.8050000@oracle.com>

Hi, Alexey.
When I last time looked to this code I got an impression that we have 
the next sequence of references:
_SurfaceDataOps.sdObject->CGLSurfaceData.graphicsConfig->CGLGraphicsConfig
In this case the java side cannot be deallocated while we have a 
reference in native. Why it does not work? Probably it will be simpler 
to fix this case instead of creation of the separate map of references?

On 30/12/15 00:26, Alexey Ushakov wrote:
> Hello,
>
> Here is the fix for openjdk9 of the crash in OGL pipeline on OSX , please have a look. The problem is also reproducible in JDK7 and JDK8
>
> Bug :https://bugs.openjdk.java.net/browse/JDK-8146238
>
> Webrev :http://cr.openjdk.java.net/~avu/JDK-8146238/webrev.00/
>
> Issue : jdk crashes inJava2D Queue Flusher after minimising/maximising heavy swing app
> (IntelliJ IDEA for example) and changing user account, see the bug for
> more details
>
> Root cause : CGLSurfaceData native data requires CGLGraphicsConfig native data for deallocation, however after disposing appropriate java objects (CGLGraphicsConfig and CGLSurfaceData) CGLGraphicsConfig native data might be deallocated before appropriate CGLSurfaceData native data, so deallocating latter causes crash
>
> Solution : Added reference counting for CGLGraphicsConfig native data in order to dispose it after all native pointers for CGLSurfaceData objects
>
> Best Regards,
>
> Alexey
>


-- 
Best regards, Sergey.


From ajit.ghaisas at oracle.com  Thu Dec 31 10:41:53 2015
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Thu, 31 Dec 2015 02:41:53 -0800 (PST)
Subject: [OpenJDK 2D-Dev] Review request for 8144033 : [TEST_BUG] delays
 needed in RenderingToCachedGraphicsTest.java
Message-ID: <a58322f9-2de1-41e4-8f2b-0b0cbf84166e@default>

Hi,

 

      Please review the fix for JDK9.

      Webrev: http://cr.openjdk.java.net/~arapte/ajit/8144033/webrev.00/

      Bug: https://bugs.openjdk.java.net/browse/JDK-8144033

 

Issue :

      The test fails intermittently on slower systems. It passes on relatively faster systems.

 

Fix :

1.       Robot object is created earlier

2.       Added delay after fillRect() calls - the method runTest() is executed in AWT-EventQueue processing thread hence, we cannot invoke robot.waitForIdle(). Therefore,  delay() method is used.

 

Regards,

Ajit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151231/5c18795d/attachment.html>

From Sergey.Bylokhov at oracle.com  Thu Dec 31 12:17:51 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 31 Dec 2015 15:17:51 +0300
Subject: [OpenJDK 2D-Dev] Review request for 8144033 : [TEST_BUG] delays
 needed in RenderingToCachedGraphicsTest.java
In-Reply-To: <a58322f9-2de1-41e4-8f2b-0b0cbf84166e@default>
References: <a58322f9-2de1-41e4-8f2b-0b0cbf84166e@default>
Message-ID: <56851CEF.2090904@oracle.com>

Hi, Ajit.
Did you check why Toolkit.getDefaultToolkit().sync(); does not work? 
Call to sync should be enough to flush gdi,d3d,ogl pipelines(including 
native state) to make visible on the screen the call fillRect.

On 31/12/15 13:41, Ajit Ghaisas wrote:
> Hi,
>
>        Please review the fix for JDK9.
>
>        Webrev: http://cr.openjdk.java.net/~arapte/ajit/8144033/webrev.00/
>
>        Bug: https://bugs.openjdk.java.net/browse/JDK-8144033
>
> Issue :
>
>        The test fails intermittently on slower systems. It passes on
> relatively faster systems.
>
> Fix :
>
> 1.Robot object is created earlier
>
> 2.Added delay after fillRect() calls ? the method runTest() is executed
> in AWT-EventQueue processing thread hence, we cannot invoke
> robot.waitForIdle(). Therefore,  delay() method is used.
>
> Regards,
>
> Ajit
>


-- 
Best regards, Sergey.