RFR: JDK-8160285: Bootcycle builds are broken on jdk9/hs for windows i586

[David Holmes]

On 28/06/2016 9:58 PM, Erik Joelsson wrote:
> On 2016-06-28 13:50, David Holmes wrote:
>> On 28/06/2016 7:40 PM, Erik Joelsson wrote:
>>>
>>> On 2016-06-28 06:30, David Holmes wrote:
>>>> Hi Erik,
>>>>
>>>>
>>>> This may coincide with the switch from the client VM to server VM on
>>>> 32-bit Windows.
>>>>
>>> That is a very likely cause.
>>>>
>>>> Fix looks fine to me.
>>>>
>>> Thanks! But after leaving work yesterday I thought some more on it and
>>> didn't like my fix. It really was a bit of a hack. When doing a
>>> bootcycle build, the jvm arguments should be based on the bits of the
>>> target rather than the original bootjdk. If the host has a small amount
>>> of memory, that should also affect the bootcycle build. Here is a new
>>> webrev which solves it in a more correct way.
>>>
>>> http://cr.openjdk.java.net/~erikj/8160285/webrev.top.02/
>>
>> Bit harder to follow. Very unclear about this:
>>
>> JVM_HEAP_LIMIT_GLOBAL=`expr $MEMORY_SIZE / 2`
>>
>> This seems like a bit of guesswork (though I'm unsure where
>> MEMORY_SIZE is coming from). If it is a small memory system then the
>> default _32/_64 values may be too small and you may get an OOME during
>> VM initialization. But if you shrink the heap the you will just get an
>> OOME during the build. I'd rather set the _32 and _64 heap sizes to
>> specific values and fail fast if the machine is too small to handle it.
>>
> It is a bit arbitrary, I agree. I intentionally didn't change that part
> of the logic, just moved it around a bit so that it applies to both the
> real bootjdk and the bootcycle boot jdk arguments. I do believe -Xmx512M
> is still enough for a working build even though I haven't tried it since
> I originally wrote that logic. A bigger heap makes the build faster
> however, which is why we by default try for a higher number.

Ok. I'm not sure it needs to be that "clever" but as long as the 
original issue is fixed and all other bootcycle buiolds are okay, then ok.

Thanks,
David

> /Erik
>> David
>>
>>> /Erik
>