harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando" <senaka...@gmail.com>
Subject Re: Define needed indicate that gc_gen is built independently
Date Thu, 03 Apr 2008 13:29:49 GMT
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
>

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