github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
00:16
pamplemousse_ joined
00:18
pamplemousse left
00:40
pamplemousse_ left
|
|||
ugexe | i wonder if these were ever checked... github.com/MoarVM/MoarVM/blob/a601...2044-L2056 | 01:15 | |
not a whole-lot to check | |||
01:47
ggoebel left
02:12
AlexDani` joined
02:16
AlexDaniel left
06:03
domidumont joined
06:09
AlexDani` is now known as AlexDaniel,
AlexDaniel left,
AlexDaniel joined
06:11
domidumont left
06:12
domidumont joined
06:46
domidumont left
06:49
AlexDaniel left
06:51
domidumont joined
07:07
domidumont left
07:08
domidumont joined
07:56
brrt joined
08:18
brrt left
08:20
sena_kun joined
09:01
leont joined
09:37
AlexDaniel joined
10:07
domidumont left
10:15
AlexDaniel left
10:21
domidumont joined
10:22
domidumont left
10:48
leont left
11:17
sena_kun left,
sena_kun joined
11:20
sena_kun left
11:31
brrt joined
11:34
dogbert11 joined
11:49
ggoebel joined
11:54
pamplemousse joined
|
|||
pamplemousse | \o | 11:54 | |
12:02
domidumont joined
12:12
AlexDaniel joined
12:14
domidumont1 joined
12:18
domidumont left
|
|||
timotimo | o/ | 12:25 | |
pamplemousse | \o timotimo | ||
12:35
AlexDaniel left
|
|||
pamplemousse | I was able to get "hello world" working out of an ELF file! Still a bit of a hack, but it's getting there | 12:44 | |
I've written up what I did here: yakshavingcream.blogspot.com/2019/...world.html | 12:45 | ||
timotimo | oh, nice | 12:49 | |
brrt | \o | 12:54 | |
pamplemousse | o/ | ||
timotimo | interesting. right now it's going via "system" to the perl6 command, but maybe it'l possible to steal the majority from the perl6 repo's src/vm/moar/runner/main.c | 12:55 | |
12:55
ggoebel left
|
|||
timotimo | and then dynamically or statically linking libmoar.so | 12:55 | |
perhaps grabbing all the pieces of mbc that belong to the startup process, including ModuleLoader for example, into separate sections in the ELF file and teaching moar to look there for specific paths? | 12:56 | ||
maybe it's still too early for that | |||
brrt | pamplemousse++ nice post | ||
timotimo | oh, here's perhaps an interesting point: you can set MVM_COVERAGE_LOG=/dev/stderr (or some filename) when executing an nqp or perl6 or whatever; that will print every line as soon as it's encountered for the first time. that can hopefully give you a good look at what pieces of code participate in the startup procedure | 12:59 | |
pamplemousse | That's really useful, thank you | ||
Right now I'm working on isolating the startup stuff to see if I can get the MBC for that, tack it on at the beginning of whatever program I'm actually trying to run, and see if that works. | 13:02 | ||
brrt: Thanks! | |||
Maybe that will be more complicated than I'm thinking it will be though | 13:03 | ||
timotimo | i'm not yet entirely following, but i.ll be AFK for a while first anyway | ||
good post indeed, tho | 13:04 | ||
pamplemousse | Thanks! | 13:05 | |
brrt | pamplemousse: I kind of expect you'll hit some complication, but i think that'll be the gist of it | 13:06 | |
one thing that MoarVM has to do, I think, is bootstrap the object system | |||
jnthn knows more about that than I do | |||
pamplemousse | Is there somewhere you know of that I could read about that? | 13:08 | |
brrt | hmmm | 13:11 | |
I thought it'd be possible to compile a simple nqp file ... | 13:12 | ||
I'm actually not quite sure | 13:14 | ||
That's digging into compiler internals that I don't know all that well | 13:15 | ||
aha, turns out that saying this: | |||
nqp-m --target=mbc ~/Code/Scratch/hello-world.nqp --output=hello-world.moarvm | |||
works, | |||
and | |||
nqp-m --target=mbc ~/Code/Scratch/hello-world.nqp --output=hello-world.moarvm | |||
this does not | |||
and then you can run 'MVM_COVERAGE_LOG=/dev/stderr moar hello-world.moarvm' with that | 13:16 | ||
pamplemousse | I think those are the same? The two lines that work and don't work? | 13:17 | |
brrt | order of arguments | ||
jnthn | Well, bootstrapping the object model is part of creating a MoarVM instance | 13:18 | |
I figure any generated executable would make a call to that | |||
I figure the goal is to create a standalone executable with all the things bundled into it? | |||
brrt | ultimately, that'd be awesome | ||
pamplemousse | brrt: They're in the same order? | ||
brrt | pamplemousse: I'm an idiot | 13:19 | |
jnthn | brrt: What's the immediate goal? | ||
pamplemousse | jnthn: That's the ultimate goal, but right now I'm aiming for an executable which contains the program itself and can run and call out to libraries on the system that its being run on. | 13:20 | |
brrt | jnthn: some kind of executable, but it doesn't have to be all-in-one at the start | ||
pamplemousse | Similar to .NET Core's framework dependent executable | ||
brrt | right | ||
what would be very nice, if it could embed the precompiled libraries as well | 13:21 | ||
this would help a bunch in startup time | |||
since the OS loader could map them all in memory at once, without having to look them up from disk | |||
(it is my theory that one of the main reasons that JVM startup is slow, is that java class loading is hostile to efficient loading strategies) | 13:22 | ||
ideally, this would be a tool to have 'fast-start' perl6 applications | 13:23 | ||
I think that if we can wrap the moar bytecode in a (linkable) elf, and the dependencies as well, then fully static linking is a matter of tooling | 13:24 | ||
but that's also just a theory | |||
jnthn | So for now you'd just include the entrypoint MoarVM bytecode and then it loads all of the others from disk, as per usual? | 13:26 | |
(Disclaimer: didn't yet read the latest post :)) | 13:27 | ||
pamplemousse | That's the thought. | ||
brrt | if you can get the library paths to be set up correctly, then I think that ought to work | 13:28 | |
jnthn | Yeah, indeed | ||
brrt | which you could probably embed into the ELF as well? the trick would then be to initialize moar correctly | 13:29 | |
timotimo | do you know how python.exe allows you to just concatenate a .zip file to the end of it and it'll load modules from inside there? | ||
at least i think that's a thing that exists or existed | 13:30 | ||
jnthn | brrt: Yeah, pretty much. I guess one easy way to Proof Of Concept this is just to generate a C file with the bytecode in a byte array and doing the appropriate initialization logic | 13:31 | |
timotimo: That's cute | |||
brrt | yeah, that's a nice hack | ||
pamplemousse | Huh, that's neat | 13:32 | |
timotimo: Not sure how similar this is, but there's xar, which was Facebook making a similar thing that was initially intended to work for multiple languages: github.com/facebookincubator/xar | 13:45 | ||
It's interesting | |||
timotimo | when i considered building tat kind of thing myself, i think i ran into ,how the hell am i going to fopen the current process's file portably?!" | 13:49 | |
hm, ok, xar requires squashfs and fuse, that's not portable either | 13:50 | ||
13:51
lucasb joined
14:29
domidumont joined
14:31
domidumont1 left
14:33
lizmat joined
14:44
brrt left
14:48
domidumont left,
domidumont joined
14:50
lizmat_ joined
14:52
lizmat left
14:54
AlexDaniel joined
15:17
domidumont left
|
|||
Kaiepi | does --no-jit disable just the legojit or both jits? | 15:23 | |
timotimo | should disable both | 15:24 | |
i'm not sure we have a configure flag to disable the expr jit at compile time | |||
we do have that env var for run time, though | |||
Kaiepi | would it be a good idea to add configuration flags to disable each individually? the legojit in particular is problematic on openbsd because it requires fstab to be configured to have W^X enabled | 15:27 | |
at least i think | 15:28 | ||
15:32
leont joined
|
|||
jnthn | Kaiepi: The expr JIT builds on the legojit | 15:34 | |
Kaiepi | oh | ||
15:36
lizmat_ left
|
|||
Woodi | I read somewhere that on openbsd /usr/local have W^X disabled by default | 15:40 | |
Kaiepi | 111ad17933e39c09.h /usr/local ffs rw,wxallowed,nodev 1 2 | 15:41 | |
looks like you're right | |||
jnthn | "ffs"? :) | 15:44 | |
Kaiepi | lmao | 15:45 | |
that's on all the lines except for swap | |||
15:57
BinGOs_ joined
|
|||
dogbert11 | anyone up for a valgrind gist? | 16:04 | |
gist.github.com/dogbert17/74e32577...fd7d4e0008 # problem in decode_stream.c | 16:06 | ||
timotimo | hm, so cur_sep_pos was 0 when it hit that line? | 16:09 | |
dogbert11 | I guess so | 16:11 | |
I can try to verify | |||
16:12
BinGOs_ is now known as BinGOs
|
|||
timotimo | if sep_graphemes was size 0, then graph_length in decode_stream_sep_from_strings was 0, too? | 16:12 | |
dogbert11 investigates ... | 16:13 | ||
16:13
BinGOs left,
BinGOs joined
|
|||
timotimo | num_seps is checked to be less than or equal to 0xFFF, but 0 would be okay it seems like, except maybe the rest of the code gets surprised by that? | 16:13 | |
i mean, if there are no separators, why would that code even run | |||
oh | |||
did someone set "" as the separator and expecting that to mean /\n\n+/ perhaps? | |||
dogbert11 | timotimo: I added the offending code block to the gist | 16:17 | |
timotimo | $fh.nl-in = ""; | 16:22 | |
is that the one? | |||
both blocks have that one line | |||
dogbert11 | it's the second block, the one with eol => $*OUT.nl-out | 16:25 | |
timotimo: in gdb now and cur_sep_pos is indeed zero | 16:30 | ||
graph_length is also zero | 16:32 | ||
Kaiepi | am i crazy or is use_last_packet getting leaked here? hastebin.com/ewudumikiw.php | 16:37 | |
i can't check, valgrind doesn't run on my os | 16:38 | ||
timotimo | Kaiepi: could very well be that libuv handles that particular data | 16:43 | |
it also has "allocate something for me pls" callbacks for example | |||
maybe that's related | |||
Kaiepi | libuv isn't being used here, this is in src/io/syncsocket.c | 16:44 | |
16:53
benchable6 joined
16:55
greppable6 joined,
reportable6 joined
16:57
nativecallable6 joined,
squashable6 joined
18:00
domidumont joined
18:03
sena_kun joined
18:20
domidumont left
18:48
pamplemousse left
|
|||
dogbert11 | timotimo: still around? | 19:01 | |
.tell timotimo shouldn't there be a 'mp_neg(i, i);' after this line? github.com/MoarVM/MoarVM/blob/mast...ops.c#L190 | 19:09 | ||
yoleaux | dogbert11: I'll pass your message to timotimo. | ||
timotimo | oh snap. that could very well be, yeah | 19:25 | |
yoleaux | 19:09Z <dogbert11> timotimo: shouldn't there be a 'mp_neg(i, i);' after this line? github.com/MoarVM/MoarVM/blob/mast...ops.c#L190 | ||
MasterDuke | Kaiepi: do you have some code i could run in valgrind to check if there's a leak? | 19:34 | |
Kaiepi | gimme a sec | 19:35 | |
MasterDuke, this *should* work but i can't test atm hastebin.com/bimukuwuje.rb | 19:39 | ||
19:43
leont left
|
|||
MasterDuke | Kaiepi: i changed the `loop` to `for ^100` so it would run for a more deterministic amount of time hastebin.com/oxidivafoj.coffeescript | 19:44 | |
19:44
pamplemousse joined,
sena_kun left
|
|||
MasterDuke | with --full-cleanup hastebin.com/cowitebuxu.coffeescript | 19:46 | |
19:51
ggoebel joined
|
|||
MasterDuke | if anyone is interested, gist.github.com/MasterDuke17/e2e32...5b8a866426 is what valgrind shows as leaking for `perl6 --full-cleanup -e ''` | 19:52 | |
Kaiepi | i forgot about my vps lmao | 19:54 | |
i'll check and see if freeing it does anything or not | 19:55 | ||
20:01
brrt joined
|
|||
Kaiepi | freeing it leaves ~3MB less memory allocated on my system | 20:05 | |
looks like a leak | |||
Geth | MoarVM: Kaiepi++ created pull request #1125: Fix memory leak in socket_read_bytes |
20:11 | |
timotimo | shows how widespread usage of IO::Socket::Async is compared to IO::Socket::INET )% | 20:15 | |
%) | |||
ugexe | it would surprise me if IO::Socket::Async was used significantly more than IO::Socket::INET | 20:16 | |
you couldnt even use SSL with ::Async till 1 or 2 years ago | |||
timotimo | .o( but cro! ) | 20:20 | |
20:20
lucasb left
20:28
lizmat joined
20:52
lizmat left
22:14
AlexDaniel left
22:36
brrt left
22:40
pamplemousse_ joined
22:43
pamplemousse left
22:47
ggoebel left
22:56
lizmat joined
|