Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
00:08
mef left
00:13
mef joined
00:19
mef left
00:23
mef joined
00:50
mef left
00:54
mef joined
01:07
mef left
01:11
mef joined
01:15
mef left
01:20
mef joined
01:34
mef left
01:38
mef joined
01:47
mef left
01:51
mef joined
01:54
mef left
02:00
mef joined
02:11
mef left
02:15
mef joined
02:18
mef left
02:22
mef joined
02:48
mef left
02:54
mef joined
03:09
mef left
03:13
mef joined
03:18
mef left
03:23
mef joined
03:34
mef left
03:38
mef joined
03:47
guifa left
03:59
mef left
04:04
mef joined
04:22
mef left
04:27
mef joined
04:33
mef left
04:37
mef joined
04:41
mef left
04:45
mef joined
04:57
mef left
05:01
mef joined
05:04
mef left
05:09
mef joined
05:26
mef left
05:30
mef joined
05:41
mef left
05:46
mef joined
05:48
mef left
05:53
mef joined
06:09
mef left
06:14
mef joined
06:21
mef left
06:25
mef joined
06:31
mef left
06:35
mef joined
06:40
mef left
06:43
mef joined
06:55
mef left
07:00
mef joined
07:27
mef left
07:32
mef joined
07:39
mef left
07:44
mef joined
07:50
mef left
07:53
mef joined
07:57
mef left
08:01
mef joined
08:04
mef left
08:08
mef joined
08:13
mef left
08:18
mef joined
08:20
mef left
08:26
mef joined
08:32
mef left
08:35
mef joined
08:39
mef left
08:43
mef joined
08:45
mef left
08:50
mef joined
08:54
mef left
08:58
mef joined
09:01
mef left
09:06
mef joined
09:14
mef left
09:18
mef joined
10:27
guifa joined
10:31
librasteve_ joined
11:00
guifa left
12:18
guifa joined
|
|||
timo | ah, hehe. whenever we run code that has been compiled, we have methods of the compiler on our stack, and that of course includes the compiler object itself, which also references the grammar and actions, and the backend and what-not :) | 14:54 | |
in theory, we could ask the compiler to give us the compiled thing and run it ourselves after the compiler has returned it, getting around that one particular stumbling block | 14:55 | ||
but the compiler and backend also do a bunch of complex stuff related to like different commandline flags you may pass, and running the code with profiling, and stuff like that | 14:56 | ||
lizmat | so we should lift the argument handling out of NQP, so we *could* get rid of it? | 15:00 | |
timo | i'm not sure what exactly the necessary changes are. all that matters is that once we invoke the actual user code, there's no longer any reference to the Compiler instance anywhere. which may be more difficult than expected if we're unlucky | 15:24 | |
even when the direct / clear references are gone, there's things like the StaticFrame holding on to other StaticFrame objects that were seen during execution, and type objects of classes that were arguments to the sub, or came from deconts or whatever, which is all related to spesh | 15:25 | ||
lizmat | how would that relate to nqp::getcomp("Raku" ) ? | 15:28 | |
timo | ah, good question, i don't know how the compiler registry works. it's possible that for that reason we can't easily get rid of the compiler related modules even if we don't compile anything | 15:33 | |
oh, btw, do we load both Perl6::{Grammar,Actions} and Raku::{Grammar,Actions} with "use" from like, main.nqp or so? because that may cause us to always load both even if we only want one of the two variants | 15:37 | ||
16:03
gfldex left
16:05
gfldex joined
|
|||
timo | yeah it does look like a simple -e '' will load both the perl6 grammar/actions and the raku grammar/actions | 16:18 | |
not sure if anything in the perl6 grammar will immediately pull in the raku grammar as a dependency or something, but there's definitely something early on that does it | |||
i wrote up a patch to do dynamic module loading for the grammar and actions modules | 16:44 | ||
aw it's still doing it | 16:45 | ||
i think i compiled without "make install" maybe that's what did it | 16:49 | ||
but that led me to a spot a few lines further down that was installing Raku::Grammar and Raku::Actions in an hll sym, so that will want patched up | 16:50 | ||
inside setup-RakuAST-WHO, the load_module call for Perl6::BOOTSTRAP::v6c is giving me "Cannot iterate over a VMNull type object" in src/vm/moar/ModuleLoader.nqp:412 in merge_globals | 17:17 | ||
not sure why that happens like that | |||
lizmat | re "oh, btw, do we load both Perl6::{Grammar,Actions} and Raku::{Grammar,Actions} with "use" from like, main.nqp or so? because that may cause us to always load both even if we only want one of the two variants" | 17:36 | |
yes we do, afaik | 17:37 | ||
it's in main.nqp | |||
first 4 lines: | |||
use Perl6::Grammar; | |||
use Perl6::Actions; | |||
use Raku::Grammar; | |||
use Raku::Actions; | |||
I guess the idea behind it is that sooner or later the "use Perl6::Grammar" and "use Perl6::Actions" will go | 17:38 | ||
Geth | MoarVM/debugserver_refactor_thread_state_check: 889db36631 | (Timo Paulssen)++ | 3 files WIP on handling threads in stolen state we have to give the thread a chance to clear its state when it was asked to participate in GC and the GC run is already over. |
17:39 | |
MoarVM/debugserver_refactor_thread_state_check: fe33b821eb | (Timo Paulssen)++ | src/debug/debugserver.c tiny whitespace fix |
|||
timo | 134028maxresidentk to 136140maxresidentk on main, 131096maxresidentk to 131500maxresidentk on that rakudo branch i pushed | 17:50 | |
not an enormous difference, but probably welcome anyway? | 17:51 | ||
0.07276 +- 0.00205 seconds time elapsed ( +- 2.81% ) / 477,103,221 cycles # 5.398 GHz ( +- 2.51% ) - main | 17:54 | ||
0.061108 +- 0.000406 seconds time elapsed ( +- 0.66% ) / 398,978,092 cycles # 5.359 GHz ( +- 0.52% ) - load_only_one | 17:55 | ||
for just rakudo -e '' | 17:56 | ||
lizmat | that looks nice :) | 17:57 | |
would that affect further execution as well ? | |||
and is that about this branch? | |||
timo | all it does is not load both modules with "use" but instead call into ModuleLoader | 17:59 | |
but also as the commit message says, RAKUDO_RAKUAST=1 makes it not work :) | |||
what do you mean by "further execution" exactly? | 18:01 | ||
lizmat | that... :-) it doesn't, it's only affecting the startup | ||
which commit are you talking about ? | 18:02 | ||
timo | yeah, only startup, plus the tiniest amount of time spent in major GC runs from just having fewer total objects | ||
the rakudo commit | |||
lizmat | did you push that already? I don't see it ? | ||
timo | oh did i forget? | ||
sorry, there it is! | 18:03 | ||
22:30
librasteve_ left
|