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 <[EMAIL PROTECTED]> wrote: > On Thu, Apr 3, 2008 at 1:03 PM, Senaka Fernando <[EMAIL PROTECTED]> > 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 < > [EMAIL PROTECTED]> > > > > > > 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 <[EMAIL PROTECTED]> > > > wrote: > > > > On Thu, Apr 3, 2008 at 4:26 AM, Alexei Fedotov < > [EMAIL PROTECTED]> > > > 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 < > [EMAIL PROTECTED]> > > > 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 >
