Binary builds and workspaces

[Stuart Monteith]

On 30/04/18 20:12, Aleksey Shipilev wrote:
> On 12/11/2017 09:57 AM, Per Liden wrote:
>> 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 a>
> 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.
nd 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.
> 
> Yes. Meanwhile, I got most Linux targets building, and buildbot also publishes the build/configure
> logs. You can use these to see where the build support is lacking in current zgc/zgc:
>   https://builds.shipilev.net/openjdk-zgc/
> 
> -Aleksey
> 
> 

Does the SPARC Solaris version build?

In src/hotspot/cpu/sparc/gc/z/zBarrierSetAssembler_sparc.cpp :
	  __ call_VM_leaf(L7_thread_cache, barrier_load_at_entry_point());

The call to ZBarrierSetAssemblerBase::barrier_load_at_entry_point()
should be passed "decorators" if it is to be correct.

I tripped over this today when rebasing my aarch64 port onto v83. I'm
currently debugging it as something is going wrong in my code.

BR,
	Stuart