Binary builds and workspaces

Per Liden per.liden at
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:
>>>>    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.


> 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