openjdk,icedtea - Xmx option mandatory

[Roberto Mannai]

After some debug I have found the following:

* File collectorPolicy.cpp:

>From CollectorPolicy::initialize_size_info() I have:
_max_heap_byte_size = align_size_up(MaxHeapSize, max_alignment()) = 512 mb.
where
max_alignment() = 2 mb
MaxHeapSize = 512 mb

Then into TwoGenerationCollectorPolicy::initialize_size_info() I have:
_max_heap_byte_size = 536870912 (512 mb)
_max_gen0_size = 41287680 (39,375 mb)
_max_gen1_size = _max_heap_byte_size - _max_gen0_size = 495583232 (472.625 mb)

Then into MarkSweepPolicy::initialize_generations() I have:
_generations[0] = new GenerationSpec(Generation::DefNew,
_initial_gen0_size, _max_gen0_size);
_generations[1] = new GenerationSpec(Generation::MarkSweepCompact,
_initial_gen1_size, _max_gen1_size);

* Going to the file genCollectedHeap.cpp:
In the method GenCollectedHeap::allocate(), I have:

total_reserved = 512 mb
total_reserved += perm_gen_spec->max_size();
total_reserved = 576mb

So adding the max size of PermGen sums up to 603979776 bytes.

I found no call to os:: memory related functions from os_linux.cpp
(os::available_memory() or os::physical_memory()).
physical_memory is called by arguments.cpp only when there is a
UseParallelGC or AggressiveHeap option.

In conclusion: it seems to me that, running without the Xmx option,
MaxHeapSize values 512 because is so defined in
hotspot/src/share/vm/runtime/globals.hpp. Adding the max perm size to
the two generations max sizes returns the value of 576 mb, which is
greater of my RAM (512 mb). That's all for me, I hope this can help
you.

Ciao
Roberto Mannai

On Tue, Aug 19, 2008 at 5:25 PM, Roberto Mannai <robermann at gmail.com> wrote:
> Hi
> A quick update.
>
> On 8/11/08, Mark Wielaard <mark at klomp.org> wrote:
>> Hi Roberto,
>> In one of your traces that you posted at:
>> https://bugzilla.novell.com/show_bug.cgi?id=414462
>> You see that the java launcher tries to allocate (mmap2)
>> 603979776 bytes aka 576 MB on your machine, just before the failure,
>> which you clearly don't have.
>
> I started to debug the JVM, and the wrong result can be read into:
> openjdk/hotspot/src/share/vm/memory/genCollectedHeap.cpp:193
>
> When looping for three times, I have:
> print total_reserved
>         0
> print total_reserved
>  41287680 = 39,375 mb
> print total_reserved
>  603979776 = 576mb
> print _n_gens
> 2
>
> The lines are the following:
>  for (int i = 0; i < _n_gens; i++) {
>   total_reserved += _gen_specs[i]->max_size();
> *** break and print total_reserved ***
>   if (total_reserved < _gen_specs[i]->max_size()) {
>     vm_exit_during_initialization(overflow_msg);
>   }
>   n_covered_regions += _gen_specs[i]->n_covered_regions();
>  }
>
> The problem seems related to the generations. I'll continue the analysis.
>
> Ciao
> Roberto Mannai
>
>>
>> If you could help us figure out where/what precisely is guessing
>> something wrong for your setup that would be nice. I don't immediately
>> have a suggestion. But start by tracing which of the os::*memory()
>> functions in openjdk/hotspot/src/os_cpu/*/vm/os_*.cpp are called and
>> what they return in your setup would be a good start.
>>
>> There seems to be a second bug during the cleanup after the abort
>> because of too limited memory. That is the "** glibc detected *** java:
>> free(): invalid pointer" you are seeing. Something is probably freeing
>> something that was never allocated in this case.
>>
>> Cheers,
>>
>> Mark
>>
>>
>