s390x port progress: patch queue for hotspot assembled.

[Volker Simonis]

On Mon, Jul 4, 2016 at 5:33 PM, Daniel D. Daugherty
<daniel.daugherty at oracle.com> wrote:
> On 7/4/16 1:10 AM, Volker Simonis wrote:
>>
>> On Sun, Jul 3, 2016 at 2:16 PM, David Holmes <david.holmes at oracle.com>
>> wrote:
>>>
>>> Hi Goetz,
>>>
>>> On 1/07/2016 9:00 PM, Lindenmaier, Goetz wrote:
>>>>
>>>> Hi Java and s390x fans!
>>>>
>>>> I want to report about the progress in the s390x port project.
>>>>
>>>> I have been working internally on the port of hotspot.
>>>> I arranged a preliminary patch queue that adds all required
>>>> hotspot  to build openJdk hotspot from our internal s390x port.
>>>> As expected, the amount of shared changes required is very low.
>>>>
>>>> I need the following 9 changes, annotated with the known T-shirt sizes:
>>>>
>>>> L: All the required includes of s390x files in shared files and all
>>>> places
>>>>      where the string s390x is needed.
>>>
>>>
>>> I'd really like us to collectively expend some brain cycles on figuring
>>> out
>>> how to do away with the explicit platform include lists. The ever
>>> expanding
>>> list of platforms really bugs me (as it has since it was introduced).
>>>
>> An obvious solution to this problem would be to simply remove the
>> os/arch parts from the corresponding filenames (they are encoded in
>> the directory path anyway) and only use the correct include path for
>> every platform while building (I think we already do that). E.g.
>>
>> Rename all instances of "assembler_<cpu>.hpp" to "assembler_cpu.hpp"
>
>
> Don't know if this is still true, but at one point the various
> IDEs were not happy with multiple files with the same name
> (ignoring the path that got you there)...
>

At one point various IDEs were not happy with multiple functions with
the same name and we definitely have this situation now. This was one
of the main reasons why I switched from NetBeans to Eclipse a few
years ago (and I don't know if NetBeans has fixed this by now).

Users usually have two kind of project setups:

1. You set up a distinct project/configuration for each platform. In
such a setup there are no problems with the current file layout and
there won't be with the renamed files as every project/configuration
will only contain a single instance from every set of files with the
same name. From my experience, such a setup works quite well in
current versions of Eclipse.

2. You want to set up a project/configuration which contains the
sources from all platforms. This is already complicated today because
you have to define all the different ARCH and OS variables and you
will inevitably get multiple instances of the same classes, methods
etc. Code navigation will not be optimal but for example Eclipse will
usually offer you a list of possible targets from which you can
choose. Such a setup is quite shaky today already and I don't use it
often anymore. Getting this right is complicated and I suppose that
having different files with the same filenames won't change the
situation dramatically to the worse.

> Dan
>
>
>
>> (i.e. cpu/x86/vm/assembler_x86.hpp -> cpu/x86/vm/assembler_cpu.hpp) in
>> which case:
>>
>> #ifdef TARGET_ARCH_x86
>> # include "assembler_x86.hpp"
>> #endif
>> #ifdef TARGET_ARCH_sparc
>> # include "assembler_sparc.hpp"
>> #endif
>> #ifdef TARGET_ARCH_zero
>> # include "assembler_zero.hpp"
>> #endif
>> #ifdef TARGET_ARCH_arm
>> # include "assembler_arm.hpp"
>> #endif
>> #ifdef TARGET_ARCH_ppc
>> # include "assembler_ppc.hpp"
>> #endif
>> #ifdef TARGET_ARCH_aarch64
>> # include "assembler_aarch64.hpp"
>> #endif
>>
>> could be simply replaced by:
>>
>> # include "assembler_cpu.hpp"
>>
>> The only drawback would be that we may have to create some empty files
>> for some platforms, but in my eyes that's not that bad.
>>
>> The current naming schema is probably a reminiscence of the old
>> includeDB days which only very aged hotspot developers can remember :)
>>
>>> Cheers,
>>> David
>>>
>>>
>>>
>>>> M: A row of S390_ONLY() macros in shared code, e.g. C1 requires some
>>>>        of them.
>>>> 6xS: Six 'X' size changes are currently needed that add a new field to a
>>>>      shared datastructure or an argument to a method.
>>>>
>>>> XL: The s390x and linux_s390x files.
>>>>
>>>> TODOs:
>>>>
>>>> -          I probably need to do some fixes in hotspot, and adapt some
>>>> functionality
>>>>
>>>> as our internal port is at jdk9 b107.
>>>>
>>>> -          Get the jdk build working.
>>>>
>>>> -          Run tests and fix issues.
>>>>
>>>> Best regards,
>>>> Goetz.
>>>>
>>>>
>