github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 08:35
nwc10 good *, jnthn 11:45
(and just as I'm going AFK for lunch)
jnthn Hm, no sign of the commit bot 11:53
tellable6 2020-10-04T06:44:33Z #raku <Xliff> jnthn: ^^ Errors when attempting to run RakuAST code from branch
jnthn github.com/MoarVM/MoarVM/pull/1380 anyway
[Coke] waves. 13:00
ggoebel jnthn++ 13:28
nwc10 good *, brrt 14:17
not #brrt (which I tried, and got very confused as to why tab completion didn't help me) 14:18
brrt good * nwc10 14:25
tellable6 2020-11-11T08:53:45Z #moarvm <nwc10> brrt Well, you have a bit more choice now: geizhals.eu/?cmp=2414598&cmp=2422055 (of course this doesn't work very well because the two products are in different categories)
brrt so attributes are sorted by category in geizhals, good to know :-P 14:37
nine Looks like using an allow list managed by HLL code to filter dependencies of a comp unit is harder than expected. Assembling a useful allow list was actually easier and it's useful for catching unwanted references to unrelated SCs. It gets hard when I want to deal with those. 15:15
I figured when encountering one, I'll just add the object (or STable) to the current SC and serialize it as if it originated in the current compilation. That'd properly take care of things we get from the Int or parametrics caches. Copying them would be totally fine. 15:16
But objects reference a ton of things. Among them their STables which will contain e.g. method caches. And copying those doesn't work because code objects aren't mere objects but reference frames which are managed totally differently. 15:17
brrt hmm 15:17
nine The point where it currently breaks is actually not even Int or parametrics cache related. The allow list cought a reference from NativeCall::Compiler::MSVC to NativeCall::Compiler::GNU (which is compiled earlier in the same process) by way of the NativeCall::Compiler stash. This slipped through because nothing tried to load NativeCall::Compiler::MSVC on its own. 15:19
jnthn In theory, method caches are going away with the new-disp work, but I guess they're just one example 15:22
nine jnthn: almost the more important message to me is that you _didn't_ cry out about what craziness the idea of an allow list and copying stuff was ;) 15:38
Or maybe you did so in real life and will take me aside at the earliest opportunity and tell me privately that I ought to consider a different career like mowing lawns or so 15:40
jnthn nine: I've not been following enough to have the context, alas.
The problem here comes down to our separate compilation not being so separate when we do it in process, though? 15:41
nine Yes. This just exposes all the places where we do have global state like the Int and parametrics caches in the VM and also the Stash hierarchy in the Raku layer. I have already defused much of the latter by not actually serializing most of them and instead generating code to assemble them in the dependencies+deserialize frame. 15:44
jnthn Well, the int and parametrics one differ somewhat, in so far as the int one is an optimization, but the parametrics one is for correctness 15:48
nine In this case it's the stub package that's throwing in the wrench. We start compiling NativeCall which creates the NativeCall packages. Then we do the nested precompilation for NativeCall::Compiler::GNU which creates the NativeCall::Compiler stub to put GNU into. This stub has to be serialized and it will. Later we get the same stub when compiling NativeCall::Compiler::MSVC 15:49
jnthn Ah, yes
And later both get discarded
nine I think the allow list approach is a good solution for Int and parametrics caches. Ints are simple and builting anyway and the parametrics caches contain only type objects and STables - which won't have their own methods. So copying them should be OK. 15:50
jnthn What's being copied, the cache or the things in it? 15:51
nine The things we get from the cache
jnthn Hmm 15:52
Not quite sure I follow then, in that the goal of the "cache" is actually to intern them
nine I copy those things during serialization, so the copies will not be used at runtime and only written to the mbc. On loading we intern them anyway 15:53
It's really just a "pretend we created those parametrics during the current compilation" during serialization 15:54
jnthn ah, I see
nine Oh, I may have an idea for the stub package. I already implemented a cleanup after precompilation. Symbols added via Perl6::World::install_package_symbol_unchecked get removed again after compilation (to be added again when we actually load the module). But I don't do so yet for stub packages. 15:55
Oh, I do. They also go in via install_package_symbol_unchecked 15:56
Ok, I think I'll just have to debug this to find out how that package actually leaks in 15:57
jnthn wonders if this could be at all helped by, instead of .WHO being directly hung off STable, instead being a lookup keyed on it, and thus we can create a fresh view of it for nested compilations 16:01
nine Less tight coupling could open up possibilities, yes 16:22

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!