February 2011 - Tachyon-list - mailman.iro.umontreal.ca

Memory usage for parsing
by Erick Lavoie 01 Mar '11

01 Mar '11

On the good side, we have squashed enough bugs to start parsing after the bootstrap. On the less good side, even with a heap of 256MB we are unable to parse the fibonacci program because too much memory is being allocated. Maxime thinks we might be able to do it if we optimize the current implementation of the parser (and the rest of the compiler...). I think that given the current implementation, we might need a GC to be able to bootstrap. To test it on your own machine, simply run "make bt-parser" with the latest revision of the master branch. I'll try to find how much memory tachyon allocates on d8 when compiling fibonacci. Erick

4 6

Low funds, reduce, reuse, recycle
by Marc Feeley 28 Feb '11

28 Feb '11

Well, my funds have run dry a bit sooner than expected. So there will be no new equipment purchases before the next instalment from NSERC in April. I recently purchased two powerful computers for the lab. Benoit is using a workstation (tawa) with a fast Intel quad core CPU with 16 GB of RAM and a 128 GB SSD. We also have a new server (12 cores, 48 GB RAM) that will be installed soon. Maxime, you say you would benefit from a fast Linux machine for which you have administrator privileges. How about installing "virtual box" (http://www.virtualbox.org/) on tawa and the server and installing Linux in it? With virtual box we could easily test Tachyon on different operating systems without switching machines. Marc

2 1

What's Missing
by chevalma＠iro.umontreal.ca 25 Feb '11

25 Feb '11

At this point we can compile all of the Tachyon code and initialize all of the code units. Our bootstrap is still not *quite* there yet, however. I've been spending most of the day finishing up code intended to make all of our C extensions accessible under the bootstrapped Tachyon (eg: readFile, writeFile, shellCommand, allocMachineCodeBlock, etc.). At this point, all the code is written and compiles, although some of it is hard to test outside of the Tachyon bootstrap. We still need two things to be done before Tachyon can truly execute once compiled: 1. Yesterday I discovered what appears to be a backend bug when compiling ptrToByteArray (runtime/ffi.js). This should hopefully be a minor fix. 2. Because we don't support byte arrays mapped to memory like V8 does, I made a wrapper to write bytes into a machine code block. We will need to change the backend code to write bytes using writeToMachineCodeBlock (see runtime/mcb.js). This should be a fairly trivial refactoring. Once this is done, Tachyon should have everything it needs to run (and compile code) in bootstrapped mode. We will probably make Tachyon drop into its shell once the bootstrap is successfully completed. What remains then is to eliminate the remaining bugs in our system. I suspect we will easily run out of memory (since our heap is currently fixed at 64MB), so I've added a heap limit pointer to the context (we will get an error if this limit is exceeded). The best we can do for now, in terms of debugging, is probably to add more assertions to our code, and use Marc's debugging traces. On this topic, Marc, did you have time to write code to log function returns? If we can know more precisely where Tachyon crashes, it will probably be a huge time saver. I will be in the lab this Monday, doing my best to squash the remaining bugs. - Maxime

1 0

Tachyon initialization complete
by Marc Feeley 25 Feb '11

25 Feb '11

I have managed to work around the d8 GC bug by adding the --nocollect_maps when invoking d8. That means that after 10 minutes of execution on my MacBook Pro, the "make bootstrap" ends with: ... Linking machine code for: "backend/x86/config.js" Linking machine code for: "backend/x86/ir-to-asm.js" Linking machine code for: "backend/x86/asm.js" Linking machine code for: "main.js" Tachyon initialization complete Yay! Now... how do we actually execute the bootstrapped Tachyon? I guess the champagne bottle won't be spending much more time in the fridge... ;-) Marc

3 2

V8 bug
by Marc Feeley 24 Feb '11

24 Feb '11

It seems that the GC bug in V8 is something the V8 developers have been aware of for some time, but have not been able to track down and debug because they don't have a deterministic test setup where they can reproduce the bug. I sent them a message on this wiki: http://code.google.com/p/chromium/issues/detail?id=59688 and they responded with: Comment 15 by project member vegorov(a)chromium.org, Today (3 hours ago) These are amazing news, Marc! Yes we would very appreciate a reproduction! CreateBackPointers traverses map's transition tree and creates back pointers (from transition target to it's source). This is a preparation step for a full garbage collection. GC will use these pointers to properly handle maps which are no longer used by any live object but still should be retained because they are part of the path between two used maps. So I suggest that we create a tar ball we can send them with the relevant sources, and instructions on how to recompile d8, and how to reproduce the bug. Who can take charge of this? Marc

2 2

Bus Error...
by Erick Lavoie 23 Feb '11

23 Feb '11

Following Marc suggestion to execute d8 in gdb to be able to inspect the stack frame after the error, we found that the error originates from d8 in the garbage collector: Generating machine code for: "ir/ast-to-ir.js" Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000023 0x001ee138 in v8::internal::Map::CreateBackPointers () (gdb) bt #0 0x001ee138 in v8::internal::Map::CreateBackPointers () #1 0x001de423 in v8::internal::MarkCompactCollector::CreateBackPointers () Previous frame inner to this frame (gdb could not unwind past this frame) I tried compiling d8 in debug mode but I still get the same error (the address was 0x0000000d for that run). For the record, Map::CreateBackPointers can be found in v8/src/objects.cc. I am wondering if some of our extensions might not interact well with the gc. Erick

2 1

Review utility/num.js
by Erick Lavoie 22 Feb '11

22 Feb '11

Overall the code is really well done and clear. However here is some issues I ran into: bignum_from_js: Using ">>" and "&" breaks when n is not representable on 32 bits, see 11.7.2 and 11.10 in ECMAScript 5. Ex: d8> Math.pow(2,30) >> 29 2 d8> Math.pow(2,32) >> 31 0 Bitwise arithmetic in javascript is done on 32 bits integer. That means we cannot create a bignum from a js number which takes more than 32 bits to represent. bignum_mod: In javascript, the sign of the result is the sign of the dividend, see 11.5.3 (ES 5). For uniformity, I think we might want to stick to the same convention. Erick

2 2

Parser Debugging Tools
by chevalma＠iro.umontreal.ca 22 Feb '11

22 Feb '11

I'm in the process of trying some of the more basic Tachyon code in Tachyon and I think we're at the point where we will be needing more powerful debugging tools. Marc, I remember you mentioning you had code for an ast pass that added print statements at the entry and exit of functions. Could you implement a parser flag to enable this in Tachyon? This will help me solve those annoying segfaults. - Maxime

2 1

JavaScript Performance Data
by chevalma＠iro.umontreal.ca 20 Feb '11

20 Feb '11

I found out that the Computer Language Benchmark Game has some performance data for JavaScript on both V8 and TraceMonkey: http://shootout.alioth.debian.org/ You can compare the performance against other language implementations for the same benchmarks, such as G++: http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=… http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=tracemonk… Apparently this was run under a recent version of V8. It's nice to see that there's still a significant performance gap, and hence room for improvement. The pidigits benchmark is one on which both implementations do extremely poorly. - Maxime

2 1

Good News!
by chevalma＠iro.umontreal.ca 19 Feb '11

19 Feb '11

I added support for the >>> operator to the constant propagation and ran a "make bootstrap". The good news is that all the code passed through the front end and all CFG validation tests. It got to the actual code generation stage and then we encountered a bug in the back-end. If we're optimistic, all that's left is fixing bugs in the back-end and we should be able to say the bootstrap is complete. Realistically, there will probably be other bugs in other parts of the system, but those will only show up when we try to run our own code. I will probably spend the rest of the afternoon adding more unit tests to try and make sure we really have our bases covered. Perhaps include some of our own code in a unit test, or try coding a simple parser, to have something more reflective of the code we actually run. I should also add the /hir, /lir, /asm shell commands because they will probably be very useful debugging tools in the next few days. - Maxime

2 4