Merge ppc port into jdk7u-dev
Andrew Hughes
gnu.andrew at redhat.com
Thu Jul 21 15:52:52 UTC 2016
----- Original Message -----
> On 21/07/16 15:46, Andrew Hughes wrote:
> >
> >
> > ----- Original Message -----
> >> On 11/07/16 16:33, Andrew Hughes wrote:
> >>
> >>>>> On 11/07/16 15:28, Andrew Hughes wrote:
> >>>>> I don't really want to lose all the history with just one huge
> >>>>> patch either.
> >>>>
> >>>> In practice, from merging in ports, that is by far the best thing
> >>>> to do. The history can be found in the development tree.
> >>>
> >>> That's certainly not my experience. Having the history available
> >>> on the working tree has proved invaluable on several occasions.
> >>
> >> I'm sure, but it makes an awful mess of the history of the tree
> >> being merged into. No.
> >
> > It means when I'm backporting patches, I can actually tell what
> > the changes are and why they were made, rather than just pointing
> > back to one mega-patch.
>
> I'm aware of the disadvantages. However, it's more important that
> the whole port be reviewable as a single patch.
Reviewing the patch is a one time event. The result has to be
maintained for possibly years to come.
As a compromise, I suggest doing a single patch for the main
patch import (up to changeset 9ee6abf28de9) which corresponds
to the whole port in the same way the initial AArch64 port was
done, and gets rid of the problematic changesets.
The remaining changesets, which either have OpenJDK bug IDs or
could trivially be assigned them, should be imported
as-is, so they will then be recorded as fixed in OpenJDK 7, rather
than being lost in a mega patch.
These are the remaining changes:
8016491: PPC64 (part 2): Clean up PPC defines.
8016586: PPC64 (part 3): basic changes for PPC64
8017313: PPC64 (part 6): stack handling improvements
8016696: PPC64 (part 4): add relocation for trampoline stubs
8019517: PPC64 (part 102): cppInterpreter: implement G1 support
8019973: PPC64 (part 11): Fix IA64 preprocessor conditionals on AIX.
8019929: PPC64 (part 107): Extend ELF-decoder to support PPC64 function descriptor tables
8017317: PPC64 (part 7): cppInterpreter: implement support for biased locking
8024468: PPC64 (part 201): cppInterpreter: implement bytecode profiling
8024344: PPC64 (part 112): C argument in register AND stack slot.
8033168: PPC64: gcc 4.8 warning in output_c.cpp
PPC64: Support for ABI_ELFv2.
8035396: Introduce accessor for tmp_oop in frame.
8036976: PPC64: implement the template interpreter
New files for template interpreter
8037915: PPC64/AIX: Several smaller fixes
8036767: PPC64: Support for little endian execution model
8042309: Some bugfixes for the ppc64 port
Adapt aix to 8022507
Fix aix after 8022507: SIGSEGV at ParMarkBitMap::verify_clear()
8050972: Concurrency problem in PcDesc cache
8050942: PPC64: implement template interpreter for ppc64le
Changes to make aix compile after the merge
8069590: AIX port of "8050807: Better performing performance data handling"
8078482: ppc: pass thread to throw_AbstractMethodError
8080190: PPC64: Fix wrong rotate instructions in the .ad file
8034797: AIX: Fix os::naked_short_sleep() in os_aix.cpp after 8028280
8139421: PPC64LE: MacroAssembler::bxx64_patchable kill register R12
8139258: PPC64LE: argument passing problem when passing 15 floats in native call
8148487: PPC64: Better byte behavior
8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions
Of the five without bug IDs, 'New files for template interpreter' should
be combined with 8036976 and the rest can trivially be assigned one.
I'm willing to do the import of these if Goetz does the initial port
import. I know from bringing most of these changes over to IcedTea
that many of them are small fixes that would be lost in a big port
changeset.
>
> > And, again, can we leave this until *AFTER* the CPU?
>
> Yes.
>
> Andrew.
>
>
>
--
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
More information about the jdk7u-dev
mailing list