problem with ClassLayout.parseClass

[Aleksey Shipilev]

Excellent. It has been a while since last release, might be this week.
How important is this for you?

-Aleksey.

On 05.11.2014 23:52, Nezih Yigitbasi wrote:
> Yep the problem is fixed with your latest change. Thanks for the quick
> fix. When can you push a new release to the maven central repo?
> 
> On Wed, Nov 5, 2014 at 12:41 PM, Aleksey Shipilev
> <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>> wrote:
> 
>     On 05.11.2014 23:27, Aleksey Shipilev 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
> 
>     Should be fixed now with:
>       http://hg.openjdk.java.net/code-tools/jol/rev/c58aecad901f
> 
>     Can you confirm?
> 
>     -Aleksey.
> 
>