harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando" <senaka...@gmail.com>
Subject Re: [gc][gc-haromy-5] Parrot's discussion on GC Improvements
Date Mon, 14 Apr 2008 11:25:07 GMT
Hi Alexei,

Yes, they do have docs online, at [1]. However, that doesn't seem to have
the glossary. The glossary found in the parrot source is available online at
[2]. GC documentation, is found at [3]. I'm at present getting the "why is
Buffer not documented?" question sorted. Hope to get this answered by
tonight (I'm +5.30 UTC), as the GC folks haven't yet turned up.

[1] http://www.parrotcode.org/docs/
[2] http://www.parrotcode.org/glossary.html
[3] http://www.parrotcode.org/docs/pdd/pdd09_gc.html

Regards,
Senaka

On Mon, Apr 14, 2008 at 10:51 AM, Alexei Fedotov <alexei.fedotov@gmail.com>
wrote:

> Senaka,
> Thanks for the interesting reading!
>
> I have a hint which you may find useful: it is possible to write to a
> list, keeping another one in CC. Did you managed to locate a Parrot
> glossary?  I found reading Parrot texts difficult because I have no
> idea what are Parrot buffers (= java arrays of primitive types?). Is
> there any place where Parrot PODs are extracted into something
> readable and nice looking?
>
> Thanks.
>
> On Sun, Apr 13, 2008 at 4:19 PM, Senaka Fernando <senakafdo@gmail.com>
> wrote:
> > ---------- Forwarded message ----------
> >  From: chromatic <chromatic@wgz.org>
> >  Date: Sat, Apr 12, 2008 at 1:23 PM
> >  Subject: Re: The Big Three Rakudo (and Parrot OO) Bottlenecks
> >  To: parrot-porters@perl.org
> >  Cc: Bob Rogers <rogers-perl6@rgrjr.dyndns.org>
> >
> >
> >
> >  On Friday 11 April 2008 19:05:41 Bob Rogers wrote:
> >
> >  >    From: chromatic <chromatic@wgz.org>
> >
> >
> > >    The free object list is the reason that compacting/copying
> collectors
> >  >    are popular, specifically that all you have to do to find the next
> >  >    free object is bump the pointer by sizeof (header) and see if
> that's
> >  >    still within the bounds of the pool.
> >  >
> >  > You don't even need the bounds check, strictly.  Several popular free
> >  > Lisps just blindly initialize the last word of the new object, and if
> >  > that segfaults, the allocation is restarted after creating a new
> pool.
> >  > But I don't know if it's really worth it for anything smaller than a
> >  > cons (two pointers).
> >
> >  I can see that working, but I'm a little leery of catching segfaults in
> a
> >  cross-platform way (and the cost of that context switch... hmm, have to
> >  benchmark that), but I'm more worried that there won't be a segfault
> because
> >  the next page happens to be in already-allocated memory somewhere and
> we're
> >  overwriting something else.  We have multiple pools of different sizes.
> >
> >
> >  > Wouldn't it be better to have the GC trigger after the next X bytes
> or
> >  > objects are allocated, rather than using the end of the pool?  The
> pool
> >  > boundary seems pretty arbitrary to me.
> >
> >  Possibly.  I'm not sure how that interacts with the three-color
> incremental
> >  scheme in the PDD, though.  We could go for the low-latency system or a
> very
> >  conservative system or a high throughput system, but I need to think
> more
> >  about the implications of the documented system.
> >
> >
> >  > Weren't we just recently having a problem with special treatment for
> >  > constant PMCs?  Full support for magic flying ponies is gonna cost
> you,
> >  > and it'll probably be in terms of reliability.
> >
> >  I know, but once in a while refcounting has its advantages....
> >
> >  -- c
> >
>
>
>
> --
> With best regards,
> Alexei
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message