Parrot 2.9.1 Released

[Jonathan Leto]

Howdy,

I was under the impression that our new default GC is better designed,
but still does not have optimal behavior in terms of memory use. Most
people don't feel it because they have lots of memory.

Am I wrong about that?

Duke

On Wed, Oct 20, 2010 at 5:44 AM, Andrew Whitworth <wknight8111 at gmail.com> wrote:
> This thread does raise a few important questions. Most notably, why is
> Parrot eating up so much memory? At least, it does appear to be eating
> more memory than it had been in months past.
>
> Total amount of memory used by Parrot is really proportional to the
> number of strings and PMCs that we have in the system. Other users of
> memory, such as global structures (interpreter, etc), method caches,
> vtables, and the C stack really don't grow as quickly as the number of
> PMCs and STRINGs grow. So the question is whether we have more GCables
> alive at any given time, or whether the cost of each GCable has
> increased. I think that the size of the PMC header has actually
> decreased by at least one pointer size since 1.0. I also don't think
> the GC algorithm has changed in any kind of way that would have added
> additional overhead to each GCable header since then.
>
> We certainly have changed the way strings work, so I wouldn't be
> surprised if we were less aggressive now about freeing up unused
> string memory. We may also be more conservative in some places about
> keeping PMCs alive longer than they need to be. I can't think of
> anything else off the top of my head that would lead us to have
> progressively worse memory numbers for completing similar tasks. Does
> anybody else know what is going on here, or have any good ideas?
>
> --Andrew Whitworth
>
>
>
> On Wed, Oct 20, 2010 at 8:29 AM, James E Keenan <jkeen at verizon.net> wrote:
>> Christoph Otto wrote:
>>
>>> Parrot 2.9.1 News:
>>> - This is a bugfix release to address a excessive slowdown in the Rakudo
>>> Perl 6 build. If you run out of memory on a box with < 512 MB physical
>>> RAM, please report it to us.
>>>
>>>
>>
>> With the reversion undertaken in 2.9.1, the burden of "unbearable slowness"
>> in build times for Parrot and Rakudo have been taken off the shoulders of
>> Rakudo and placed back on those of the users of smaller resource boxes.
>>
>> On my machine with 256MM phys mem, I recorded these times:
>>
>> 'make' took          28:54
>> 'make smoke' took 2:08::51
>>
>> So (to use a distinction employed by chromatic in #parrotsketch yesterday),
>> this reversion did not "break" Parrot in the sense of causing an error which
>> prevented build or run, but it did make it so slow as to render development
>> on this machine unfeasible.
>>
>> Thank you very much.
>> kid51
>>
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>



-- 
Jonathan "Duke" Leto
jonathan at leto.net
http://leto.net