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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > wrote: > > ---------- Forwarded message ---------- > > From: chromatic <[EMAIL PROTECTED]> > > Date: Sat, Apr 12, 2008 at 1:23 PM > > Subject: Re: The Big Three Rakudo (and Parrot OO) Bottlenecks > > To: [EMAIL PROTECTED] > > Cc: Bob Rogers <[EMAIL PROTECTED]> > > > > > > > > On Friday 11 April 2008 19:05:41 Bob Rogers wrote: > > > > > From: chromatic <[EMAIL PROTECTED]> > > > > > > > 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 >
