[aarch64-port-dev ] RFR: initial patches for merge up to jdk8-b117

[Andrew McDermott]

Hi,

> On 14 Dec 2013, at 10:41, Andrew Haley <aph at redhat.com> wrote:
> 
>> On 12/13/2013 06:29 PM, Andrew McDermott wrote:
>> 
>>>> However, I did ran into problems with some of the jtreg tests using all
>>>> the available memory on my machine (32GB). That, combined with only a
>>>> 100MB swap file, caused my machine to hang hard quite a few times over
>>>> the last two days and the reboots required most of my file systems to be
>>>> fsck'd, which took quite some time as there is ~4TB spread across 5
>>>> disks.  I'll run the tests again and report back which tests I believe
>>>> are using/requesting a lot of memory but right now I wanted to get these
>>>> patches out for review.
>>> 
>>> I wanted to follow up on this problem.
>>> 
>>> This spike (which you can see in the attached image) comes from running
>>> the following test:
>> 
>> I think the list swallowed the attachment.  There's a copy here:
>> 
>>  http://people.linaro.org/~andrew.mcdermott/RunUnitTestsConcurrently.png
> 
> Actually, the list rejected the whole post for being too large, and
> I trimmed and forwarded it.
> 
>>> 
>>> $ jtreg -conc:1 -v1 -a \
>>>   -retain:none \
>>>   -jdk:/jdk8-b117/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image \
>>>   runtime/memory/RunUnitTestsConcurrently.java
>>> 
>>> However, if I run using 'release' then the same memory pattern is not
>>> exhibited, and in fact the test runs very quickly - which you would
>>> expect as it's not trying to gobble 30+GB of ram.
>>> 
>>> So the reason why my machine was sometimes [1] hanging hard was due to
>>> the deliberately small swap partition I use and because I was running
>>> many other tests and builds at the same time, and typically with a
>>> concurrency factor of 10.
>>> 
>>> It's odd (and I have done zero investigation other than identify which
>>> particular test it is) as to why the same test under different build
>>> configurations behaves the way it does.
> 
> This is builtin sim?

No, x86. In fact, this build was just a checkout of the x86 tree, so no aarch64-port bits.

> 
> The debug build necessarily uses more memory, but that sounds excessive.
> It should be investigated.
> 
> Andrew.
> 
>