openjdk,icedtea - Xmx option mandatory

[Roberto Mannai]

Hi
Resuming this old post, just for close the question :); the "Could not
reserve enough space for object heap" error was caused by the limit
set by "ulimit -v" on my opensuse box, by files /etc/sysconfig/ulimit
and /etc/initscript.

ulimit -v is set to the 80% of physical ram + swap on my opensuse 11.1.

So, given the new defaults for Xmx in openjdk, the java process
allocation size is greater than the ulimit max size set during the
boot of machine and fails to start.

Ciao
Rob

On Wed, Aug 20, 2008 at 10:48 PM, Roberto Mannai <robermann at gmail.com> wrote:
>
> 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
> >>
> >>
> >