problem with ClassLayout.parseClass

[Nezih Yigitbasi]

Hi Aleksey,
Thanks for the quick reply and opening the bug report. I will definitely
give it another try once it’s fixed.
The actual call made is
ClassLayout.parseClass(ArrayList.class).instanceSize() to determine the
size of an arraylist instance. Is there another method in jol that we can
use to work around this problem instead of disabling explicit gc calls in
production?

Thanks again,
Nezih
​

On Wed, Nov 5, 2014 at 12:27 PM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> Hi Nezih,
>
> On 05.11.2014 22:33, Nezih Yigitbasi wrote:
> > We are seeing a weird GC problem with the jol library with the
> > ClassLayout.parseClass() call. The problem is that the calling
> > thread spends a lot of time doing full GCs and it’s kind of stuck in
> > a GC loop. We only observed this problem with the
> > -XX:+UseConcMarkSweepGC and -XX:+ExplicitGCInvokesConcurrent flags
> > where the explicit System.gc() call in the VMSupport.guessAlignment()
> > method cause full GCs that are very slow (when these flags are
> > removed I see less number of full GCs that are much faster and I
> > don’t see the problem anymore). This seemed like a bug to me, but I
> > just wanted to check with you to understand it better.
>
> Well, that code is running once during the initialization, and it does
> indeed calls for GC to condense the newly allocated array with objects
> to better estimate the alignment.
>
> I would agree that unexpected System.gc coming from a library is a
> library bug, and therefore we can revisit this, filed:
>   https://bugs.openjdk.java.net/browse/CODETOOLS-7901085
>
> -Aleksey.
>
>