bootcycle build on ix86-linux-gnu broken since jdk-13+18

[Ioi Lam]

I tried the steps in my previous mail and the build suceeded.

build$ ./images/jdk/bin/java -Xshare:on -Xinternalversion -version
Java HotSpot(TM) Server VM (14-internal+0-2019-06-18-1551218.iklam.null) 
for linux-x86 JRE (14-internal+0-2019-06-18-1551218.iklam.null), built 
on Jun 18 2019 08:54:10 by "iklam" with gcc 8.2.0
build$ ./images/jdk/bin/java -Xshare:on -version
java version "14-internal" 2020-03-17
Java(TM) SE Runtime Environment (build 
14-internal+0-2019-06-18-1551218.iklam.null)
Java HotSpot(TM) Server VM (build 
14-internal+0-2019-06-18-1551218.iklam.null, mixed mode, sharing)

But ... the funny thing is:

build$ find . -name \*.jsa | xargs ls -l
-r--r--r-- 1 iklam dba  8286208 Jun 18 09:06 
./bootcycle-build/images/jdk/lib/server/classes.jsa
-r--r--r-- 1 iklam dba 18751488 Jun 18 08:51 ./configure-support/classes.jsa
-r--r--r-- 1 iklam dba  8286208 Jun 18 09:01 
./images/jdk/lib/server/classes.jsa

The size of ./configure-support/classes.jsa is exactly the same as my 
regular x64 build. So it looks like we got it from the boot-jdk (which 
for me happens to be 64 bit). Notice that none of the JVM binaries under 
my build directory is 64-bit:


build$ find . -name libjvm.so | xargs file
./support/interim-image/lib/server/libjvm.so: ELF 32-bit LSB shared 
object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
./support/modules_libs/java.base/server/libjvm.so: ELF 32-bit LSB shared 
object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
./hotspot/variant-server/libjvm/gtest/libjvm.so: ELF 32-bit LSB shared 
object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
./bootcycle-build/support/modules_libs/java.base/server/libjvm.so: ELF 
32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically 
linked, not stripped
./bootcycle-build/hotspot/variant-server/libjvm/gtest/libjvm.so: ELF 
32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically 
linked, not stripped
./bootcycle-build/images/jdk/lib/server/libjvm.so: ELF 32-bit LSB shared 
object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
./bootcycle-build/jdk/lib/server/libjvm.so: ELF 32-bit LSB shared 
object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
./images/jdk/lib/server/libjvm.so: ELF 32-bit LSB shared object, Intel 
80386, version 1 (SYSV), dynamically linked, not stripped
./jdk/lib/server/libjvm.so: ELF 32-bit LSB shared object, Intel 80386, 
version 1 (SYSV), dynamically linked, not stripped


Matthias, could you try running your build again with a boot jdk that's 
32-bit?

I think we have a couple of issues here:

+ CDS handling of mismatched archive files
+ Wrong JDK is used to generate ./configure-support/classes.jsa during a 
bootcycle build.

Thanks
- Ioi

On 6/18/19 8:54 AM, Ioi Lam wrote:
> Matthias,
>
> Could you send the exact steps for reproducing this? Are you doing 
> something like this?
>
>    cd openjdk13src
>    mkdir build
>    cd build
>    bash ../configure -- --with-target-bits=32
>    make bootcycle-images
>
> Thanks
> - Ioi
>
>
> On 6/17/19 2:35 AM, Matthias Klose wrote:
>> On 17.06.19 09:45, David Holmes wrote:
>>> <dropped jdk-dev>
>>>
>>> < cc'ing Calvin>
>>>
>>> Hi Matthias,
>>>
>>> This looks like an issue with the new Dynamic Archive support. I'm 
>>> not sure if
>>> it is intended for use on 32-bit, but it looks like the size of the 
>>> file to map
>>> is too large. (or it may relate to the issue Aleksey pointed too - 
>>> either way it
>>> starts from dynamic archive code.)
>> yes, configuring with --disable-cds works around the build failure.  
>> Looking at
>> the other 32bit hotspot build, it looks like the armhf build works 
>> with enabled cds.
>>
>> Matthias
>>
>>> Cheers,
>>> David
>>>
>>>
>>>
>>> On 15/06/2019 12:02 am, Matthias Klose wrote:
>>>> On 14.06.19 15:10, David Holmes wrote:
>>>>> Hi Matthias,
>>>>>
>>>>> On 14/06/2019 10:57 pm, Matthias Klose wrote:
>>>>>> My last successful bootcycle build on i686-linux-gnu was 
>>>>>> jdk-13+18. After
>>>>>> that I
>>>>>> tried jdk-13+22, which didn't build anymore, with no change to 
>>>>>> the most recent
>>>>>> jdk-13+25, and also seen in jdk-14+1.
>>>>>>
>>>>>> All builds fail with
>>>>>>
>>>>>> Compiling 12 properties into resource bundles for jdk.jdeps
>>>>>> #
>>>>>> # There is insufficient memory for the Java Runtime Environment 
>>>>>> to continue.
>>>>>> # Native memory allocation (malloc) failed to allocate 2155274940 
>>>>>> bytes for
>>>>>> AllocateHeap
>>>>>> # An error report file with more information is saved as:
>>>>> Do you have the full stack for that? It might shed some light.
>>>> now attached.
>>>>
>