Aligning all objects to 8-byte boundaries will loose a lot of space in the heap, also it is not only an issue when allocating in new-space, but when allocating in ole space as well (I don't think we allocate tenured HeapNumbers though). Also during both scavenge and compacting garbage collection this property needs to be preserved. One option would be to have the alignment in new-space only, and then make a separate space for HeapNumbers, where each HeapNumber would occupy 4 words, this would waste one word per heap number though. There are already separate spaces for some fixed sized objects. If you want to start out with aligning all HeapNumbers make sure to place heap filler objects when skipping a work for allocation purposes as the GC needs this for consistency.
Regards, Søren On Thu, Sep 24, 2009 at 19:03, Rames <[email protected]> wrote: > > Actually I did not change much in architecture independent code to get > the shell compile: I only added the mips #ifdef V8_TARGET_MIPS and > alikes, and added the mips architecture to scons files. > Of course the shell did not and (and still does not work), so I am > changing some code but right now it is still only testing. But don't > worry I will remember to submit my changes regularly. > > Right now I am trying to fix errors I meet when I run the shell, and I > have a few questions. I'll ask them here since they are port issues. > > Running the shell on MIPS I got a double alignment problem. v8 uses 4- > bytes aligned addresses for HeapObject, and thus for HeapNumber. The > double value contained in the HeapNumber has an offset of 4 bytes. But > on MIPS we need doubles to be 8-bytes aligned. Browsing the code I > found that allocation of such HeapObjects ended calling some > AllocateRaw function, but I could not find a system controling this > alignment: It seems everything is 4 bytes aligned because we only ask > for multiples of 4 sizes allocation. > > The patch I found is to always round up the allocated size to a > multiple of 8 (and change the double offset in HeapNumber so that it > is 8-bytes aligned), changing > Address new_top = alloc_info->top + size_in_bytes > to > Address new_top = alloc_info->top + RoundUp(size_in_bytes, 8); > in NewSpace::AllocateRawInternal and PagedSpace::AllocateLinearly . > > Is there some way to control alignment that I missed or do we need > something like that? > > Thanks. > > Alexandre > > On Sep 24, 1:58 am, Erik Corry <[email protected]> wrote: > > 2009/9/22 Rames <[email protected]> > > > > > > > > > I did not find documentation about how to port v8, but as Dean McNamee > > > suggested, going through x64 commit logs was interesting. Of course > > > the most teaching step was to read the code, which is very well > > > documented! > > > > > I am still just at the beginning of the port. I can now compile the > > > shell, and begin the real porting part. I think I will start a wiki to > > > keep track of and explain which main steps I follow and what issues I > > > meet. > > > > If you have made changes to compile the shell I think you should get them > > integrated. We are much happier reviewing small changes than one huge > > change at a later date. > > > > You should consider putting in a simple, slow MIPS simulator. The ARM > > simulator is only around 2000 lines of code and it is enormously useful > when > > debugging. The way it was done with ARM was that an unimplemented > > instruction error gives an error message that tells you exactly what > > instruction was hit. Then you implement only the instructions that your > > back end can emit. In the beginning that is probably very few > instructions > > :-) > > > > One way to approach a port would be to copy the ARM directory, then rip > out > > most of the implementations of all the functions, replacing them with > > 'unimplemented' errors. There will be some code duplication with this > > approach, but it is nice and simple. > > > > > > > > > > > > > This may be a starting point to this documentation, and maybe more > > > experienced developers will share their experience and help. > > > > > I will give some update when I have enough info, results, and > > > experience to start the documentation. > > > > > Alexandre > > > > > On Sep 22, 6:30 am, rmckeown <[email protected]> wrote: > > > > Right now I'm not seeing much guidance around porting v8 - just the > > > > code that is already out there, so I'm currently resigned to the code > > > > and beginning to run gdb to figure out the behaviour. > > > > > > It would be great if we could distill out and document a general > > > > approach to porting as you suggest > > > > > > e.g. what key things about the target arch. must you determine, what > > > > order should attack the files. > > > > With 3 architectures now supported (ia32, x64 and ARM) the best- > > > > practices should be emerging and if we can get them documented, it'll > > > > make subsequent ports go easier. > > > > > > ...or am I mistaken, and is this info actually out there and I > haven't > > > > yet stumbled upon it? > > > > > > Thx > > > > Rob > > > > > > On Sep 13, 3:15 pm, Dean McNamee <[email protected]> wrote: > > > > > > > I would dig through the commits from William and Lasse. They > recently > > > > > implemented the x64port. It was more work than a 32-bit > > > > > architecture, since it involved also making parts of v8 work with > > > > > 64-bits. > > > > > > > I would try to follow the same path they did, which parts, tests, > etc > > > > > they started with, and how they brought the pieces together. It > seems > > > > > like a MIPSportwill be most similar to ARM, so you'll probably want > > > > > to understand how that code generator works. > > > > > > > Good luck > > > > > -- dean > > > > > > > On Sat, Sep 12, 2009 at 2:06 AM, A.Rames <[email protected]> > wrote: > > > > > > > > I am glad to say on this group that Sigma Designs wants toportv8 > to > > > > > > the MIPS architecture and plans to contribute the code when it is > > > > > > finished. > > > > > > I am a new Sigma intern and I will be working on this project > > > > > > (supervised by Sebastian Manciulea). > > > > > > > > After some time running tests, reading documentation about > dynamic > > > > > > compilation techniques, and reading v8's code, I am now thinking > > > about > > > > > > how toportv8 to MIPS. > > > > > > > > After discussing it briefly, the rough idea would be: > > > > > > - To manage to compile v8 for MIPS. (without having it work) > > > > > > - I guess I will then need to implement the whole (or most of > it) > > > > > > instruction set and test if I can correctly generate instructions > > > > > > before really porting anything else. > > > > > > - Toportgradually each element, beginning by the most > independent > > > > > > elements. (cpu.h functions, higher level description of > instructions, > > > > > > etc) > > > > > > - Continue to a higher level, beginning with the regexp part as > both > > > > > > interpreter and native mode are present. > > > > > > > > So this is my rough guess of how I should begin. However v8 > > > > > > developers' (and other's as well) opinion and advice would be a > great > > > > > > help! > > > > > > Are there any problems with my approach? Where would you begin? > Do > > > you > > > > > > have any particular warning or advice? > > > > > > > > Thanks! > > > > > > > > Alexandre > > > > -- > > Erik Corry, Software Engineer > > Google Denmark ApS. CVR nr. 28 86 69 84 > > c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen > K, > > Denmark. > > > --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
