groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <p...@asert.com.au>
Subject Re: Rolling back change to use ClassValue
Date Wed, 09 Sep 2015 10:53:06 GMT
Rollback ok by me.

Strong preference for a flag to re-enable if possible, particularly if we
are pushing back to 2.4.5. That way if people are affected by the
GROOVY-6704 memory leak and not by the ClassValue bug, then they can turn
it back on and we can easily keep testing against newer JVM releases too.

I'd also like some tests (some subset of current tests?) which can be run
on the CI server with that flag re-enabled so as to ensure the ClassValue
code doesn't get out of sync. But that can come later as time permits.

On Wed, Sep 9, 2015 at 4:19 AM, Pascal Schumacher <pascalschumacher@gmx.net>
wrote:

> o.k. then I support the rollback (reopen of
> https://issues.apache.org/jira/browse/GROOVY-6704)
>
>
> Am 08.09.2015 um 20:06 schrieb Cédric Champeau:
>
>
>> Is the memory leak it created worse than the memory leak it fixed?
>>
>> Yes, because it spreads beyond the boundaries of the classloader Groovy
> was loaded in.
>
>> -Pascal
>>
>>
>> Am 08.09.2015 um 09:07 schrieb Cédric Champeau:
>>
>>> Hi guys,
>>>
>>> As some of you may know, I've been investigating a memory leak which
>>> involves all versions of Groovy starting from 2.4. The leak comes from a
>>> bug in the VM regarding how it handles ClassValue, that Groovy 2.4 started
>>> using. All VMs are affected (7, 8 and 9) and it's still unclear when this
>>> will be fixed. So I would like to suggest to rollback this change for the
>>> next release.
>>>
>>> Basically, this commit:
>>> https://github.com/apache/incubator-groovy/commit/97d78e9e52deb52c8e66db501ef208f30384d014
>>>
>>> It greatly affects Gradle, so I would suggest to make the change ASAP
>>> (2.4.5) if everyone agrees.
>>>
>>
>>
>
>

Mime
View raw message