Binary builds and workspaces
Per Liden
per.liden at oracle.com
Mon Dec 11 08:57:35 UTC 2017
On 2017-12-11 09:44, Aleksey Shipilev wrote:
> On 12/09/2017 01:09 AM, Aleksey Shipilev wrote:
>> On 12/08/2017 01:06 PM, Per Liden wrote:
>>> On 2017-12-07 20:42, Aleksey Shipilev wrote:
>>>> *) Binary builds:
>>>> https://builds.shipilev.net/openjdk-zgc/
>>>>
>>>> x86_64 is built natively, other targets are cross-compiled. Builds are updated every night,
>>>> build frequency might change in future, in both directions. I would try to make build logs
>>>> available too, for easier debugging.
>>>
>>> I noticed that you have aarch64 and IA32 builds there. Just a heads up, the ZGC code base only
>>> supports Linux/x86_64 and Solaris/Sparc at this time.
>>
>> That's not a problem. Shenandoah currently supports Linux/x86_64 and Linux/aarch64, but we build
>> other platforms anyway, because sometimes changes in shared code may break the other platform's
>> builds. It also helps to check that unsupported configurations fail predictably and reliably.
>
> For example, aarch64 build fails with:
>
> /pool/buildbot/slaves/sobornost/zgc/build/src/hotspot/share/gc/z/zGlobals.hpp:29:33: fatal error:
> zGlobals_linux_aarch64.hpp: No such file or directory
> #include OS_CPU_HEADER(zGlobals)
>
>
> And i386 build fails with multiple errors like these:
>
> /pool/buildbot/slaves/sobornost/zgc/build/src/hotspot/os_cpu/linux_x86/zGlobals_linux_x86.hpp:83:65:
> error: left shift count >= width of type [-Werror=shift-count-overflow]
> const uintptr_t ZPlatformAddressSpaceStart = (uintptr_t)1 << ZPlatformAddressOffsetBits;
> ^~~~~~~~~~~~~~~~~~~~~~~~~~
> /pool/buildbot/slaves/sobornost/zgc/build/src/hotspot/os_cpu/linux_x86/zGlobals_linux_x86.hpp:84:66:
> error: left shift count >= width of type [-Werror=shift-count-overflow]
> const uintptr_t ZPlatformAddressSpaceSize = ((uintptr_t)1 << ZPlatformAddressOffsetBits) * 4;
> ^~~~~~~~~~~~~~~~~~~~~~~~~~
Going forward, I'm hoping we can get to a point where we don't need
"fake" platform-specific files, just to make stuff build. Instead I'm
thinking we should evolve the build system to never attempt to build a
GC if it's not supported on that platform. Think of it as a more
fine-grained INCLUDE_ALL_GCS thing, but maybe implemented differently.
/Per
>
> We were at the same position at some point, but the requirements for shipping Shenandoah with 8u
> forced us to maintain buildable workspace even on platforms Shenandoah does not support.
>
> Thanks,
> -Aleksey
>
More information about the zgc-dev
mailing list