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
