[aarch64-port-dev ] Fireside chat - Thursday 13th July

[Felix Yang]

Hi,

    How about patches like these:


http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-April/026097.html

http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2017-July/004650.html

Thanks,
Felix


On 29 July 2017 at 00:06, Andrew Haley <aph at redhat.com> wrote:

> A follow-up with regard to the AArch64 jdk8u commit policy.
>
> The policy for updates is that once a patch is known to be stable and
> has received a decent amount of testing, it can be considered for
> jdk8u.
>
>
> With regard to bug fixes, here is the policy:
>
> "Changes allowable within the Java SE 8 specification may still be
> rejected for inclusion in OpenJDK 8 if the behavioral compatibility
> risk is judged as too large. Behavioral compatibility concerns
> implementation properties of the JDK. Clients of the JDK can knowingly
> or unknowingly come to rely upon implementation-specification
> behaviors not guaranteed by the specification and care should be taken
> to not break such applications needlessly. In contrast, if a change is
> appropriate for every other JDK release train, it is generally
> appropriate for OpenJDK 8 too. Examples of such universal changes
> include security fixes and time zone information updates.
>
> "With the above caveats, bug fixes in JDK 9 that do not involve
> specification changes have presumptive validity for OpenJDK 8. That
> is, by default such fixes are assumed to be applicable to OpenJDK 8,
> especially if having "soaked" in JDK 9 for a time without incident.
>
> "As a general guideline, if a change is applicable to both JDK 9 and
> OpenJDK 8, the change should be made in JDK 9 no later than the change
> is made in OpenJDK 8."
>
> [This policy is taken from http://openjdk.java.net/projects/jdk6/]
>
> The rules for performance improvements are less clear.  I'm going to
> regard missing intrinsics as bugs and allow them as long as they are
> well-tested in JDK 9 without problems.  Note that we have had several
> serious regressions due to buggy intrinsics, so we have to be certain
> what we are doing is safe.
>
> Is this clear enough?
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>