On Fri, 5 Mar 2021 11:11:44 GMT, Alan Hayward <github.com+4146708+a7...@openjdk.org> wrote:
>>> I was building this PR on a new machine, and I now get the following error: >>> >>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:258:31: >>> > error: cast to smaller integer type 'MIDIClientRef' (aka 'unsigned int') >>> > from 'void *' [-Werror,-Wvoid-pointer-to-int-cast] >>> > static MIDIClientRef client = (MIDIClientRef) NULL; >>> > ^~~~~~~~~~~~~~~~~~~~ >>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:259:29: >>> > error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') >>> > from 'void *' [-Werror,-Wvoid-pointer-to-int-cast] >>> > static MIDIPortRef inPort = (MIDIPortRef) NULL; >>> > ^~~~~~~~~~~~~~~~~~ >>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:260:30: >>> > error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') >>> > from 'void *' [-Werror,-Wvoid-pointer-to-int-cast] >>> > static MIDIPortRef outPort = (MIDIPortRef) NULL; >>> > ^~~~~~~~~~~~~~~~~~ >>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:466:32: >>> > error: cast to smaller integer type 'MIDIEndpointRef' (aka 'unsigned >>> > int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast] >>> > MIDIEndpointRef endpoint = (MIDIEndpointRef) NULL; >>> > ^~~~~~~~~~~~~~~~~~~~~~ >>> > 4 errors generated. >>> >>> As far as I can tell the only difference between the two systems is the >>> xcode version: >>> >>> New system (failing) >>> % xcodebuild -version >>> Xcode 12.5 >>> Build version 12E5244e >>> >>> Old system (working) >>> % xcodebuild -version >>> Xcode 12.4 >>> Build version 12D4e >>> >>> Looks like the newer version of Xcode is being a little stricter with >>> casting? >>> Replacing the NULL with 0 seems to fix the issue. >> >> Hello >> there is one issue with the info you provided, it's from Xcode12.5 beta. >> And beta license agreement forbids sharing output of beta version of >> compiler&co >> So we can't say we have issue with newer xcode beta until that beta went >> public & released. >> Fixing issues you found now will mean someone have violated xcode beta >> license agreement and made these issues public. > >> Hello >> there is one issue with the info you provided, it's from Xcode12.5 beta. >> And beta license agreement forbids sharing output of beta version of >> compiler&co >> So we can't say we have issue with newer xcode beta until that beta went >> public & released. >> Fixing issues you found now will mean someone have violated xcode beta >> license agreement and made these issues public. > > Ok, I wasn't aware of that. I'll downgrade back to the non-beta version. Hi, @VladimirKempik reported failure of CompressedClassPointers.largeHeapAbove32GTest() with [JDK-8262895](https://bugs.openjdk.java.net/browse/JDK-8262895) on macos_aarch64. He also helped analyzing the issue (thanks!). Apparently the vm has difficulties mapping the heap of 31GB at one of the preferred addresses given in [`get_attach_addresses_for_disjoint_mode()`](https://github.com/openjdk/jdk/blob/8d3de4b1bdb5dc13bb7724596dc2123ba05bbb81/src/hotspot/share/memory/virtualspace.cpp#L477). This causes the test failure indirectly. IMO it could be worth the effort to find out why the heap cannot be mapped at the preferred addresses. Reviewers should decide on it. I wouldn't be able to do it myself though as I don't have access to a macos_aarch64 system. Alternatively I'd suggest to exlude macos_aarch64 from the subtest largeHeapAbove32GTest. Best regards, Richard. -- #### Details of the analysis In the following trace we see the vm trying to allocate the heap at addresses given in [`get_attach_addresses_for_disjoint_mode()`](https://github.com/openjdk/jdk/blob/8d3de4b1bdb5dc13bb7724596dc2123ba05bbb81/src/hotspot/share/memory/virtualspace.cpp#L477) without success: images/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -Xmx31g -XX:-UseAOT -Xlog:gc+metaspace=trace,cds=trace,heap+gc+exit=info,gc+heap+coops=trace -Xshare:off -XX:+VerifyBeforeGC -XX:HeapSearchSteps=40 -version OpenJDK 64-Bit Server VM warning: Shared spaces are not supported in this VM [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000001000000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000001800000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000002000000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000004000000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000005000000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0008000000000000 heap of size 0x7c1000000 [0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0010000000000000 heap of size 0x7c1000000 [0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0018000000000000 heap of size 0x7c1000000 [0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0020000000000000 heap of size 0x7c1000000 [0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0080000000000000 heap of size 0x7c1000000 [0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0100000000000000 heap of size 0x7c1000000 [0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0110000000000000 heap of size 0x7c1000000 Finally it gives up and lets the os chose the address: [0.006s][trace][gc,heap,coops] Trying to allocate at address NULL heap of size 0x7c1000000 [0.006s][debug][gc,heap,coops] Protected page at the reserved heap base: 0x0000000280000000 / 16777216 bytes [0.006s][debug][gc,heap,coops] Heap address: 0x0000000281000000, size: 31744 MB, Compressed Oops mode: Non-zero based: 0x0000000280000000, Oop shift amount: 3 The os chooses to map the heap at 0x0000000281000000 that is at 10GB. This leaves not much room for a 4GB (*) aligned compressed class space below 32G for a zero based encoding. And indeed we get a compressed class space with an encoding base that is not zero and largeHeapAbove32GTest fails then [0.007s][info ][gc,metaspace ] Compressed class space mapped at: 0x0000007000000000-0x0000007040000000, reserved size: 1073741824 [0.007s][info ][gc,metaspace ] Narrow klass base: 0x0000007000000000, Narrow klass shift: 0, Narrow klass range: 0x40000000 On macos 10.15 (x86_64) the vm succeeds first try mapping the heap at address 0x0000001000000000. (*) On aarch64 the encoding base has to be 4GB aligned. Unfortunately the 4GB alignment is enforced to strictly on the start address of the compressed class space instead of enforcing it on the encoding base. See [JDK-8258756](https://bugs.openjdk.java.net/browse/JDK-8258756) ------------- PR: https://git.openjdk.java.net/jdk/pull/2200
