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

[Erik Joelsson]

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.

/Erik
> David
>
>> /Erik