| timotimo | how come i never seem to get the fprintf stderr output from free_repr_data? | 00:45 | |
| do we just never free them? do we leak them? | |||
| flussence | fflush()? | 01:03 | |
| timotimo | i don't have to fflush when the program exits gracefully, no? | 01:04 | |
| flussence | oh well, dunno then... | ||
| timotimo | :) | 01:14 | |
| well, i do get it now | |||
| i started over from scratch by just replacing every malloc with a fixed_size_alloc, but i end up corrupting the FSA free list somehow :| | 01:18 | ||
| i think i'll head toward bed | 01:21 | ||
|
02:48
ilbot3 joined
03:28
JimmyZ_ joined
|
|||
| JimmyZ_ | timotimo: something error like github.com/MoarVM/MoarVM/issues/234 ? | 03:29 | |
|
04:35
cognominal joined
05:21
dalek joined
06:22
virtualsue joined
06:50
domidumont joined
06:55
domidumont joined
07:14
virtualsue joined
07:27
kjs_ joined
|
|||
| arnsholt | timotimo: Since you're testing stuff in P6opaque, you probably have to run with the complete cleanup flag (whose precise name escapes me at the moment) | 08:11 | |
| Since types generally live 'till program exit, and thus are not explicitly freed unless you pass that flag | |||
|
08:23
zakharyas joined
09:00
virtualsue joined
|
|||
| jnthn | timotimo: Yeah, you'll need to run with --full-cleanup | 09:43 | |
| timotimo | just popping in quickly: | 09:44 | |
| yeah, i'm running with full cleanup | |||
| no, it's nothing like "too many open files" | 09:45 | ||
| the bug i'm seeing is that some null object is getting put into "hey, can i have your Num method, please" and refuses to work with that | 09:46 | ||
| on the "timo comes up with ridiculous optimization strategies" front: we could have a global set of zeroes that we can point anything at that needs a read-only array of zeroes; i've seen many p6opaques scroll by that have at least two of their arrays filled with exclusively zeroes :) | 10:05 | ||
| my first thought was to just have those sections collapsed into one, but why not go all the way and just allocate a kilobyte of zeroes somewhere and point everything there and have it owned by the instance or threadcontext | 10:06 | ||
| or even a static array of zeroes that lives in the .text segment of the p6opaque.o? | |||
| that'd be read-only in a very safe manner | |||
| not to mention having a single global shared set of zeroes is extremely cache-friendly when you're juggling many different kinds of p6opaque | 10:24 | ||
| JimmyZ | timotimo: I didn't mean too many open files, I mean the segfault :) | ||
| timotimo | at the end of my work i didn't have a segfault | ||
| JimmyZ | you could try open the FSA DEBUG | 10:25 | |
| timotimo | the p6opaque_packed branch has the logic error, my local restart-from-scratch explodes when trying to free something in FSA | ||
| i did at some point, i don't remember with which codebase, though | |||
| arnsholt | Maybe there's a mismatch between the size you've allocated and the size you're freeing? You could try hardcoding those to test it, perhaps. Just allocate something stupid like 1024 bytes in every case, or somesuch | 10:27 | |
| timotimo | isn't that what FSA debug does? | 10:28 | |
| arnsholt | No idea, I'm afraid | 10:29 | |
| timotimo | it looked to me as if it defines a little structure that has the size in front and the blob following it | 10:33 | |
| jnthn | m: say 2.44 / 3.34 | 10:34 | |
| camelia | rakudo-moar 50a4df: OUTPUT«0.730539» | ||
| timotimo | oooh, i love it when jnthn does that ;) | ||
|
10:46
cognominal joined
10:52
zakharyas joined
|
|||
| masak | when he... divides two decimal numbers? :) | 11:09 | |
| timotimo | yes! | 11:10 | |
| especially when the result comes out between 0 and 1 | |||
| masak .oO( this has been your weekly instalment of "Weird, Specific Fetishes" ) :P | 11:13 | ||
| jnthn | m: say 3.34 / 0.08 | 11:26 | |
| camelia | rakudo-moar 50a4df: OUTPUT«41.75» | ||
| jnthn | oops | 11:27 | |
| m: say 3.34 / 0.8 | |||
| camelia | rakudo-moar 50a4df: OUTPUT«4.175» | ||
| jnthn | So, I figured out why we fail at inlining a bunch of stuff... | ||
| also, duh, that 0.8 was with spesh logging still on | 11:28 | ||
| m: say 3.34 / 0.65 | 11:29 | ||
| camelia | rakudo-moar 50a4df: OUTPUT«5.138462» | ||
| timotimo | the number is now above 1, what does that mean?!? ;) | 11:32 | |
| jnthn | ah, I did it the other way around before | 11:33 | |
| m: say 0.65 / 3.34 | |||
| camelia | rakudo-moar 50a4df: OUTPUT«0.194611» | ||
| jnthn | Runs in 19% of the time it did before | ||
| The other calc gives "around 5 times faster":) | 11:34 | ||
| timotimo | holy wow. | ||
| jnthn | This is about accessors, fwiw | 11:35 | |
| But the inline fix is far more general. | 11:36 | ||
| timotimo | right | ||
| ==29384== Invalid write of size 8 | |||
| ==29384== at 0x4FB1BCE: add_to_bin_freelist (fixedsizealloc.c:192) | |||
| ==29384== by 0x4FB1BCE: MVM_fixed_size_free (fixedsizealloc.c:205) | |||
| that doesn't seem good | |||
| jnthn | Nope, that's epic bustage | ||
| timotimo | ==29384== Syscall param write(buf) points to uninitialised byte(s) | ||
| ==29384== by 0x50050E8: MVM_mast_to_file (driver.c:75) | |||
| jnthn | That one I've seen before...think it's harmless, but worth hutning down | 11:37 | |
| timotimo | OK; that's from precompiling dependencies for the script i was meaning to test | ||
| it's recursively using perl6-valgrind-m to precompile | 11:38 | ||
| jnthn | Alas, some spectest fails to deal with | ||
| timotimo | ==29490== 16,361 (15,392 direct, 969 indirect) bytes in 481 blocks are definitely lost in loss record 3,110 of 3,554 | 11:41 | |
| ==29490== by 0x4F80E24: MVM_args_copy_callsite (args.c:57) | |||
| that's from the usecapture opcode | 11:42 | ||
| timotimo double-checks that his moar is clean | |||
| seems like p6opaque's repr data is a tiny bit leaky | |||
| or maybe free_repr_data is in general not happening for some reason? | 11:52 | ||
| jnthn | I didn't quite work those out yet. I did wonder if somehow we double-deserialize them... | 11:53 | |
| As I couldn't see any obvious source of leaks | |||
| timotimo | OK, an interesting thing to say the least :) | 11:55 | |
|
12:11
virtualsue joined
|
|||
| dalek | arVM: 05d9e14 | jnthn++ | src/spesh/inline.c: Don't do cross-HLL inlining. Otherwise, things that look into a frame's HLL will get confused. |
12:12 | |
| arVM: 2e6a1dd | jnthn++ | src/spesh/optimize.c: Fix resolution of some non-multis. We assumed that just because a code type supported multi-dispatch meant it always would be multi-dispatch when performaing various optimizations. However, in many cases the code is not actually a multi, and so we missed out on a lot of opportunities to generate 0239906 | jnthn++ | src/core/args.c: Avoid some potential uninitialized memory access. |
|||
| timotimo | oooh | 12:13 | |
| asset-3.soupcdn.com/asset/12310/83...a4_500.gif | |||
| jnthn | :D | 12:15 | |
| [Coke] gets an ERR_CONNECTION_RESET on the soupcdn link, but blames dayjob's http proxy and or firewall. | 13:37 | ||
| timotimo | probably :( | 14:41 | |
| jnthn | Pro tip: don't leave a piece of code containing a loop that leaks memory running by accident | 14:42 | |
| "Why is this machine suddenly sluggish?!" | |||
| moritz | :-) | 14:45 | |
| pro tip: when running potentially leaky code, enforce a memory limit | |||
| ulimit on linux :-) | |||
| jnthn | ;-) | 14:47 | |
| Yeah, wasn't in my Linux VM for that | |||
| masak | moritz++ # so sensible | ||
| jnthn | I only gave it a core or two, and it was valgrinding :) | ||
|
14:50
dalek joined
|
|||
| moritz | seems there are options for windows too: stackoverflow.com/questions/192876/...mory-limit | 14:50 | |
|
14:51
virtualsue joined
15:11
lizmat joined
|
|||
| arVM: a8beba2 | jnthn++ | src/core/args.c: Remove dangerous/broken usecapture optimization. It caused a huge memory leak, and we actually accidentally relied on the leak somewhere (that should have used savecapture). Overall, it's just too fragile to have userland code deciding when the optimization is safe, and the leak costs a lot. |
|||
|
15:41
virtualsue joined
16:12
hoelzro joined
16:14
flussenc1 joined
16:15
BinGOs_ joined,
timotimo joined
16:44
vendethiel joined
16:59
kjs_ joined
17:06
zakharyas joined
17:13
domidumont joined
|
|||
| dalek | arVM: a329e2d | jnthn++ | src/ (15 files): Make access to string heap go through a function. Marked as static inline, so this shouldn't have any performance consequences. This paves the way for decoding only the strings that are needed at the point of first use. |
17:22 | |
|
17:39
virtualsue joined
|
|||
| timotimo | it occurs to me, that every "on first use" or "lazy" feature kind of wants to have a way of inspecting it | 17:39 | |
| the "heap explorer" idea in my head has grown in scope already to also let you inspect bytecode and spesh code | |||
| it should clearly also let you inspect the state of lazy deserialization, because that's rather closely tied to the idea of "heap exploration" already | 17:40 | ||
| jnthn | Would be interesting, yes | 17:41 | |
| timotimo | my intuition tells me i'll want to be constructing object graphs (arrays and hashes) in the moar process and send that off to the front-end as json | 17:43 | |
| i'd have to construct a second instance for that, because GC is a thing | |||
| jnthn | grr, headache returns | 17:47 | |
| Guess I'll take a nom break :) | |||
| timotimo | good noms! | ||
|
17:59
FROGGS joined
18:23
virtualsue joined
18:32
BinGOs joined
19:26
kjs_ joined
|
|||
| jnthn | m: say 49320 - 48048 | 20:15 | |
| camelia | rakudo-moar 3176cb: OUTPUT«1272» | ||
| jnthn | 1.2MB off Rakudo base memory by lazily deserializing strings, it seems | ||
|
20:24
kjs_ joined
20:26
virtualsue joined
|
|||
| jnthn | nqp-m -e "while 1 {}" is now less than the base memory of the JVM running a Java program with such a loop in it and nothing more too, iirc :) | 20:41 | |
|
20:43
Ven joined
|
|||
| arnsholt | Nice! | 20:43 | |
| dalek | arVM/lazy-strings: eff150a | jnthn++ | src/ (4 files): First pass at making string decoding lazy. That is, we only do it the first time a string from the string heap is needed. Not quite right yet; we SEGV one of the NQP tests. But close. |
20:48 | |
| jnthn | Not gonna manage it all tonight...tired | ||
|
20:52
Ven joined
|
|||
| timotimo | that's not bad, damn. | 21:07 | |
|
22:39
vendethiel joined
22:56
virtualsue joined
23:02
vendethiel joined
23:50
vendethiel joined
23:54
virtualsue joined
|
|||
| timotimo | m: say 148 * 120 + 13 * 24 + 13 * 16 + 12 * 8 + 4 * 48 + 4 * 48 + 2 * 64 + 2 * 56 + 2 * 32 + 2 * 128 + 2 * 104 + 72 + 168 | 23:57 | |
| camelia | rakudo-moar 855de7: OUTPUT«19768» | ||
