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
