Luke Gorrie

Thanks for linking this. Yes, I suspect we should increase our default settings for the max traces and machine code size. Certain Snabb applications have also reached these limits so...

@SoniEx2 This idea is still very interesting for RaptorJIT since we want to reduce the maintenance burden of the C code and evolve the language over time. I don't think...

I'd like to understand how the current bootstrap uses embedded bytecodes (if at all.) I was going to insist that we already do generate and embed bytecodes during bootstrap. There...

@SoniEx2 That's one breadcrumb but `buildvm_libbc.h` is only directly included by other bootstrapping code. How do those library function bytecodes end up in the executable?

@SoniEx2 So is the Lua code embedded in C comments first bytecode compiled by `genlibc.lua` into `buildvm_libbc.h` which is then used to generate `lj_bcdef.h` containing these same bytecodes which is...

I created an issue at #250 so that hopefully the next time somebody goes down this build-and-bootstrap rabbit hole they could capture that into a readme of some kind.

Great tip from @CapsAdmin: There is already an implementation of the LuaJIT parser and bytecode compiler in Lua! Could we use this to retire some C code in RaptorJIT? https://github.com/franko/luajit-lang-toolkit

Good idea! I had thought that polling wouldn't be suitable but yes, logging new types right before a trace should be fine.

Thanks for this simple idea @fsfod. I've implemented it in lukego/raptorjit@90a15f7a4306416af0a2d21f620660d70536dbc6 and it's awesome to see proper C types in IR listings and diagrams now. Examples: ![screenshot 2018-05-10 10 53...

Hm. That patch is not stable. I'm occasionally seeing segfaults when calling `lj_ctype_repr()`. Have to see if that's a bonehead mistake of mine or some invariant that I don't understand...