Backport proposal of the Marlin renderer in OpenJDK8

Thu Sep 12 19:54:59 UTC 2019

Hi Andrew B (& other Andrew in this thread),

I have an idea that could satisfy both approaches:
- As the azul team backported already jdk9+ patches into their openjdk8 /
zulu repository, it implies jdk8u patches are ready for integration and I
already reviewed the code: zulu could be considered as both an incubator
that proved Marlin works on jdk8 in production (as I did on my github).

Two solutions:
- extract & apply all zulu-ready patches in order in jdk8u-dev
- extract one big patch (from zulu) and apply it on jdk8u-dev
I do not see any reason to use another incubator repository...

I can review all individual patches or the all-in-one and we are all done,
up to the last patch backported in zulu 8 (version 0.9.1.1 merged in dec
2018 according to me).

Moreover I already maintain a github branch for the Marlin / openjdk (8):
https://github.com/bourgesl/marlin-renderer/tree/openjdk?files=1
It is my reference to easily compare with any jdk8 codebase.

>From this first step, I will manage the missing patches to be up-to-date
with latest jdk14 (v0.9.1.3 ie 2 patches) and future ones.

What do you think ?
This approach requires some work from zulu team to publish jdk8 patches
that I will review and I need a jdk8u sponsor to endorse, follow & push the
patch train or the all-in-one patch integration.

Cheers,
Laurent

Le jeu. 12 sept. 2019 à 15:32, Andrew Brygin <abrygin at azul.com> a écrit :

> Hello Laurent,
>
>  thank you for your great work on the Marlin renderer.
>
>  As you know we (Azul) have already integrated Marlin into
>  Zulu 8, we are ready to help with the integration into OpenJDK 8.
>
> >> Finally I still wonder how to deal with the former classes
> (RenderingEngine
> >> conflict). How did you handle this aspect in the zulu codebase ?
>
>  In Zulu8 we have updated the rendering engine selection in order to use
>  Marlin by default. However, we have preserved the Pisces renderer just
>  in case if somebody wants to use it, and uses sun.java2d.renderer property
>  to specify Pisces explicitly.
>
>  We have registered Marlin renderer as a service in
>
>  src/share/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine
>  in order to make it available via ServiceLoader machinery.
>
>  We will be happy to share our patches, as well as test and review the
> integration.
>
> Thanks,
> Andrew
>
> > On Sep 11, 2019, at 6:41 PM, Mario Torre <neugens.limasoftware at gmail.com>
> wrote:
> >
> > I suggest to do what we are doing for JFR, which means the project
> > lead created a repository for us where we are merging individual bugs
> > (and adding new where necessary, like minor fixes only applicable to
> > 8u), with every commit accompanied by the relative bug id. Once
> > everything is done, you can propose the whole batch for integration.
> > We also mark individual bugs in Jira for the back port with a special
> > label, so they should be easier to track.
> >
> > As for who approves the patches, ideally you want to have a reviewer
> > working with you, but for the staging repository you don't strictly
> > need it since its purpose is obviously to get the patches back ported
> > and the assumption is that you are the original author so you know
> > best ;)
> >
> > Once everything is ready, a reviewer will go through the patches (or
> > the big patch) and approve it (or not!).
> >
> > Cheers,
> > Mario
> >
> > Il giorno mer 11 set 2019 alle ore 16:51 Laurent Bourgès
> > <bourges.laurent at gmail.com> ha scritto:
> >>
> >> Hi,
> >>
> >> I am wondering how to start with such big backport.
> >> - list all original patches among 9 to 14 repositories (=11u as I
> >> backported few changes already)
> >> - use my github fork of jdk8u_jdk or stay on mercurial but a new
> >> jdk8u_marlin forrest should be created ?
> >> - identify interested people (azul, adoptopenjdk, amazon) to build a
> tiger
> >> team to start the concrete work
> >> - who can sponsor (committer) / review these patches ?
> >>
> >> Finally I still wonder how to deal with the former classes
> (RenderingEngine
> >> conflict). How did you handle this aspect in the zulu codebase ?
> >>
> >> Laurent
> >>
> >>
> >> Le jeu. 8 août 2019 à 20:51, Andrew John Hughes <gnu.andrew at redhat.com>
> a
> >> écrit :
> >>
> >>>
> >>>
> >>> On 08/08/2019 08:18, Laurent Bourgès wrote:
> >>>
> >>> snip...
> >>>
> >>>>>
> >>>> This class change must stay specific to jdk8u, as a different patch.
> >>>>
> >>>> Finally I wonder if we should backport each individual jdk9, 10, 11,
> 14
> >>>> patches into jdk8u as a long train or you would accept 1 large patch
> >>>> gathering all patches.
> >>>> Of course, the latter approach seems simpler to me, but it requires a
> >>>> careful review to ascertain the code is the same with the current jdk
> >>>> repository (jdk 14).
> >>>> Once jdk8u & jdk14 have Marlin renderer 0.9.1.2, we will simply
> backport
> >>>> future changes.
> >>>>
> >>>
> >>> The individual changes should be backported. This assures that there is
> >>> a record that these bugs are fixed in 8u, which is important for
> >>> long-term maintainability.
> >>>
> >>> I would suspect the original JDK9 patch would be an easier backport
> too,
> >>> given how much the build system has changed and the files have moved
> >>> around in JDK head.
> >>>
> >>> A halfway option between the two would be to build up the required
> >>> changes in a staging repository and then ask for a bulk review before
> >>> integration into 8u. I believe this is how JFR is being backported.
> >>>
> >>> Thanks,
> >>> --
> >>> Andrew :)
> >>>
> >>> Senior Free Java Software Engineer
> >>> Red Hat, Inc. (http://www.redhat.com)
> >>>
> >>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> >>> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> >>> https://keybase.io/gnu_andrew
> >>>
> >
> >
> >
> > --
> > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> > Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
> >
> > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> > Proud GNU Classpath developer: http://www.classpath.org/
> > OpenJDK: http://openjdk.java.net/projects/caciocavallo/
> >
> > Please, support open standards:
> > http://endsoftpatents.org/
>
>
Le jeu. 12 sept. 2019 à 15:32, Andrew Brygin <abrygin at azul.com> a écrit :

> Hello Laurent,
>
>  thank you for your great work on the Marlin renderer.
>
>  As you know we (Azul) have already integrated Marlin into
>  Zulu 8, we are ready to help with the integration into OpenJDK 8.
>
> >> Finally I still wonder how to deal with the former classes
> (RenderingEngine
> >> conflict). How did you handle this aspect in the zulu codebase ?
>
>  In Zulu8 we have updated the rendering engine selection in order to use
>  Marlin by default. However, we have preserved the Pisces renderer just
>  in case if somebody wants to use it, and uses sun.java2d.renderer property
>  to specify Pisces explicitly.
>
>  We have registered Marlin renderer as a service in
>
>  src/share/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine
>  in order to make it available via ServiceLoader machinery.
>
>  We will be happy to share our patches, as well as test and review the
> integration.
>
> Thanks,
> Andrew
>
> > On Sep 11, 2019, at 6:41 PM, Mario Torre <neugens.limasoftware at gmail.com>
> wrote:
> >
> > I suggest to do what we are doing for JFR, which means the project
> > lead created a repository for us where we are merging individual bugs
> > (and adding new where necessary, like minor fixes only applicable to
> > 8u), with every commit accompanied by the relative bug id. Once
> > everything is done, you can propose the whole batch for integration.
> > We also mark individual bugs in Jira for the back port with a special
> > label, so they should be easier to track.
> >
> > As for who approves the patches, ideally you want to have a reviewer
> > working with you, but for the staging repository you don't strictly
> > need it since its purpose is obviously to get the patches back ported
> > and the assumption is that you are the original author so you know
> > best ;)
> >
> > Once everything is ready, a reviewer will go through the patches (or
> > the big patch) and approve it (or not!).
> >
> > Cheers,
> > Mario
> >
> > Il giorno mer 11 set 2019 alle ore 16:51 Laurent Bourgès
> > <bourges.laurent at gmail.com> ha scritto:
> >>
> >> Hi,
> >>
> >> I am wondering how to start with such big backport.
> >> - list all original patches among 9 to 14 repositories (=11u as I
> >> backported few changes already)
> >> - use my github fork of jdk8u_jdk or stay on mercurial but a new
> >> jdk8u_marlin forrest should be created ?
> >> - identify interested people (azul, adoptopenjdk, amazon) to build a
> tiger
> >> team to start the concrete work
> >> - who can sponsor (committer) / review these patches ?
> >>
> >> Finally I still wonder how to deal with the former classes
> (RenderingEngine
> >> conflict). How did you handle this aspect in the zulu codebase ?
> >>
> >> Laurent
> >>
> >>
> >> Le jeu. 8 août 2019 à 20:51, Andrew John Hughes <gnu.andrew at redhat.com>
> a
> >> écrit :
> >>
> >>>
> >>>
> >>> On 08/08/2019 08:18, Laurent Bourgès wrote:
> >>>
> >>> snip...
> >>>
> >>>>>
> >>>> This class change must stay specific to jdk8u, as a different patch.
> >>>>
> >>>> Finally I wonder if we should backport each individual jdk9, 10, 11,
> 14
> >>>> patches into jdk8u as a long train or you would accept 1 large patch
> >>>> gathering all patches.
> >>>> Of course, the latter approach seems simpler to me, but it requires a
> >>>> careful review to ascertain the code is the same with the current jdk
> >>>> repository (jdk 14).
> >>>> Once jdk8u & jdk14 have Marlin renderer 0.9.1.2, we will simply
> backport
> >>>> future changes.
> >>>>
> >>>
> >>> The individual changes should be backported. This assures that there is
> >>> a record that these bugs are fixed in 8u, which is important for
> >>> long-term maintainability.
> >>>
> >>> I would suspect the original JDK9 patch would be an easier backport
> too,
> >>> given how much the build system has changed and the files have moved
> >>> around in JDK head.
> >>>
> >>> A halfway option between the two would be to build up the required
> >>> changes in a staging repository and then ask for a bulk review before
> >>> integration into 8u. I believe this is how JFR is being backported.
> >>>
> >>> Thanks,
> >>> --
> >>> Andrew :)
> >>>
> >>> Senior Free Java Software Engineer
> >>> Red Hat, Inc. (http://www.redhat.com)
> >>>
> >>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> >>> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> >>> https://keybase.io/gnu_andrew
> >>>
> >
> >
> >
> > --
> > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> > Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
> >
> > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> > Proud GNU Classpath developer: http://www.classpath.org/
> > OpenJDK: http://openjdk.java.net/projects/caciocavallo/
> >
> > Please, support open standards:
> > http://endsoftpatents.org/
>
>