Talking about what I know... :) I did say "bit" :)...
Anyway, thanks to Parrot folks and their docs I got their side a bit sorted.
I'm reading on Harmony now.
Basically their heap objects have two representations.
1. PMC
2. Buffers
Each have different GC models.
Taking a PMC, they are immovable. Therefore, once created they'd be pinned
to where they are. They have several memory pools. So each particular PMC
will be pinned to a pool AFAIU. Laying out objects in heap is pool based.
They do have the free-list concept etc.
Taking buffers, they can be moved. Copying/Compacting is supported.
Also parrot runs on a 100% Heap and no stack mechanism.
Most info is from parrot/docs/pdds/pdd09_gc.pod
Regards,
Senaka
On Thu, Apr 3, 2008 at 11:03 AM, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> On Thu, Apr 3, 2008 at 1:03 PM, Senaka Fernando <senakafdo@gmail.com>
> wrote:
> > Hi Xiao-Feng, Alexei,
> >
> > Well that shouldn't take that long I guess. I'm a bit familiar now on
> the
> > Harmony end, and I have been hacking parrot's interface too. Have
> patched
> > one bug there and working on some more. They are keen in improving
> their GC
> > interface. I'm getting good cooperation on that end.
> >
> > Will work on the doc, from now, util I have something solid. I will use
> the
> > wiki for this.
> >
>
> hmm, I am not sure if you are already familiar with the Harmony end,
> since you haven't asked tough questions yet. ;)
>
> For example, one core issue: what are the object representations of
> Hamrony and Parrot? i.e., how an object is laid out in heap?
>
> Some others like, can Parrot move objects in heap? Does Parrot require
> to pin some objects in fixed positions during their lifetime?
>
> Thanks,
> xiaofeng
>
> > Regards,
> > Senaka
> >
> > On Thu, Apr 3, 2008 at 6:39 AM, Alexei Fedotov <
> alexei.fedotov@gmail.com>
> >
> >
> > wrote:
> >
> > > Senaka, that's a great idea.
> > >
> > > I fully support Xiao Feng's suggestion on documenting GC interface
> > > differences as the best step for this moment. It sets a good
> > > background. It has a quick and useful deliverable. Somehow I missed
> it
> > > when thought about planning.
> > >
> > > On Thu, Apr 3, 2008 at 4:58 AM, Xiao-Feng Li <xiaofeng.li@gmail.com>
> > > wrote:
> > > > On Thu, Apr 3, 2008 at 4:26 AM, Alexei Fedotov <
> alexei.fedotov@gmail.com>
> > > wrote:
> > > > > Senaka,
> > > > > An open source is a place where you are free to do what do you
> want.
> > > > > Let me just share my advise on being focused and don't let this
> > > advise
> > > > > to ruin your fun.
> > > > >
> > > > > At this point I would recommend you to use a control version
> system
> > > > > instead of defines. In other words, rewrite or remove portions
> of
> > > > > files freely and commit checkpoints where you are able to build
> the
> > > > > whole code base into your local control version system. When
> you get
> > > > > things working it would be easy to arrange all defines.
> > > > >
> > > > > Imagine: you may spend a day putting defines to make a file
> compile,
> > > > > and throw the whole file tomorrow since it will be rewritten
> for
> > > > > Parrot compatibility.
> > > >
> > > > Reasonable. It could be heavy-lifting at the beginning to consider
> too
> > > > much of VM-independent issues. On the other hand, it's interesting
> to
> > > > read the findings and discussions here about the issues. It
> enlightens
> > > > me to think more.
> > > >
> > > > Btw, I don't want to discourage, but can be slow down the code
> hacking
> > > > a little bit. :-) At the moment, I think the most important is to
> > > > understand the overall interface and infrastructure differences
> > > > between Harmony and Parrot. To document them could be a better
> > > > starting point, and the doc would be a strong fact to help the
> project
> > > > be approved by Google...
> > > >
> > > > Thanks,
> > > > xiaofeng
> > > >
> > > >
> > > >
> > > > > Thanks.
> > > > >
> > > > >
> > > > > On Wed, Apr 2, 2008 at 9:46 PM, Senaka Fernando <
> senakafdo@gmail.com>
> > > wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > At present, the gc_gen is built as a part of the VM, but
if
> we
> > > are to make
> > > > > > it possible for it to be built separately, a define is
> needed so
> > > that the
> > > > > > un-wanted stuff can be stripped off. How about
> GC_INDEPENDENT, as
> > > the name
> > > > > > of the define?
> > > > > >
> > > > > > Regards,
> > > > > > Senaka
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > With best regards,
> > > > > Alexei
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > http://xiao-feng.blogspot.com
> > > >
> > >
> > >
> > >
> > > --
> > > With best regards,
> > > Alexei
> > >
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>
|