| 01:47 | <Mathieu Hofman> | I suppose it's easier to prove that an interpreter can only affect the heap of the interpreted language in the first place? At that point an explicit heap sandbox may be redundant? |
| 01:49 | <Mathieu Hofman> | That's possibly where writing an interpreter in a memory safe language would help: you can reason that the only memory you can reach is the one allocated to represent the heap of the language you're interpreting. |
| 01:51 | <Mathieu Hofman> | of course you can still have bugs in the interpreter that would break the memory safety of the language you're interpreting. but you can't escape out to affect the memory of the rest of the process. |
| 03:03 | <shu> | That's possibly where writing an interpreter in a memory safe language would help: you can reason that the only memory you can reach is the one allocated to represent the heap of the language you're interpreting. |
| 03:03 | <shu> | like, the target GCed language's GC heap |
| 03:04 | <shu> | of course you can still have bugs in the interpreter that would break the memory safety of the language you're interpreting. but you can't escape out to affect the memory of the rest of the process. |
| 03:04 | <shu> | it depends on how the underlying memory safe language's memory safety is implemented, right? |
| 03:06 | <Mathieu Hofman> | Right that assumes the interpreter is implemented in a memory safe language |
| 03:07 | <Mathieu Hofman> | But I don't see how the fact the interpreted language is GCed is relevant here. |
| 03:10 | <Mathieu Hofman> | And if it's the language of the interpreter that is GCed, of course it assumes that language is memory safe, including its GC |
| 03:17 | <Michael Ficarra> | I would really love to have the GraalJS people actually come talk to us sometimes |
| 03:29 | <bakkot> | they've been to at least one meeting! |
| 05:16 | <snek> | I feel like I don't quite understand the proposed separation as it relates specifically to browsers. when I added nullish things to V8, the changes were purely in the parser and bytecode generator. I had a separate change later to the lower down parts to add a new "is null or undefined" op. isn't this already basically jssugar/js0? why does it need to be externalized to tooling rather than a separation within browser internals? |
| 07:44 | <Marja Hölttä (not here, use marja@google.com)> | Michael Ficarra: i skimmed it and what i gathered was that their JIT is an automagic transformation of the interpreter plus some speculative optimizations. i guess how practically applicable that is depends on [among other things] whether we can express all the needed speculative optimizations (object shapes and such) via their API or not. |
| 16:41 | <Mathieu Hofman> | bakkot: looks like the Matrix log archives are not updating |
| 16:43 | <bakkot> | Mathieu Hofman: ugh, thanks, looks like they changed the API or I'm running into an edge case I hadn't before |
| 16:43 | <bakkot> | will fix it sometime in the next couple of days and it'll catch up |
| 16:44 | <bakkot> | I have alerting for this sort of thing but it's on a 24hr lag |
| 17:24 | <ljharb> | lol the notes say "U4 of" instead of "you for-of" |
| 17:54 | <rkirsling> | could go a step further and make it "U4've" |