01:15 ren1us joined 01:25 cognome joined 01:40 FROGGS_ joined 02:01 colomon joined 02:19 ventica joined 02:50 ventica2 joined 02:56 ggoebel111119 joined 06:14 brrt joined
brrt timotimo: in the dynasm file they're obligatory (the // comments), because dynasm doesn't understand the other type of comments very well 06:15
in the other file they're temporary :-)
06:37 ventica2 joined
brrt optional params are ... funky 06:43
neither true accessors or branches 06:44
jnthn They either store the provided value and jump, or do nothing at all and fall through to the next instruction, which does the default handling 07:11
sergot o/ 07:13
jnthn o/ sergot 07:15
brrt yes, that's funky, isn't it? 07:31
jnthn Yes, fairly. Though also encapsulates an existence check and a retrieval 07:32
brrt i'm pondering adding a special node for it
can't do much harm i think 07:33
nwc10 brrt: what fixed the big boom bug from yesterday? 07:37
brrt uncommenting the offending lines :-(
eh, commenting them
nwc10 oh
brrt it's become remarkably difficult to actually get a findmeth line 07:45
that's isn't removed by spesh 07:46
nwc10 can you hack spesh to stop remving them?
brrt probably, yes 07:47
07:54 zakharyas joined 08:16 ventica2 joined 08:32 cognome_ joined 08:37 zakharyas joined 09:17 brrt joined 09:31 zakharyas joined
brrt jnthn: how do frame handlers work, exactly? 09:32
jnthn brrt: The handlers list is an extent list, sorted by most deeply nested first. 09:34
brrt extent list?
timotimo gets a jit log for parsing a big json document 09:38
perf claims it spends 25% in the interpreter loop
brrt o
timotimo but the per-instruction heat listing doesn't seem helpful
brrt 25% is not really that much 09:39
where's the rest of the time spent?
timotimo process worklist, then frame_invoke, then frame_dec_ref, gc_mark, at_key, gc_collect_free_gen2_unmarked 09:40
the first gc_mark is from P6opaque
brrt i'm not so surprised with frame_invoke there
jnthn Yeha, the VS profiler reckons around 28% 09:41
timotimo the second one from MVMArray
jnthn We hvae more P6opaques than anything else, so not so surprising that it's the hottest gc_mark function.
timotimo i'd like to put a little statistics collection thingie in that tells us more about how the program behaves in relation to the GC
jnthn at_key is also very hot here too 09:42
I see 5%-6% there
timotimo as in: after each minor collection, how far - percentage wise - did the pointer move back in relation to the nursery's size
jnthn Could be interesting to know. 09:43
timotimo and also something about gen2. maybe how many objects of what size got killed each time? 09:44
brrt tl;dr; semantic use of cur_interp_op is not so good for JIT 09:57
09:59 colomon joined
jnthn I guess one approach for handlers in the JIT is to use the labels to build an extent list and then look at the return address 10:00
Given you know where all the handlers are (thanks to annotations)
brrt yeah, that would basically be the core of it 10:01
but that will still require quite extensive modification in exception handling
jnthn Yes; I'm not sure I see an easy way out of teaching the exception handling code about the JIT. 10:04
brrt isn't sure if the following is cruft or much awesome 10:32
en.wikipedia.org/wiki/Direction_flag 10:33
lizmat remembers using that in her "write 8086 assembly code by hand" days 10:39
brrt madness 10:46
lizmat yup, but if you need to work with max 640KB of RAM. you start to do crazy things 10:48
11:23 brrt joined
jnthn heh, wow :) 11:38
jnthn didn't know about that :)
Mmm...lunch curry. 11:39
jnthn realizes he's now eaten curry 3 days running.
moritz running curry? /me only knows running sushi 11:40
brrt :-o 11:48
3 days of curry
dalek arVM/moar-jit: dc1b22a | (Bart Wiegmans)++ | / (5 files):
Add numeric comparison operators
 12:12
brrt should an object WHO ever be zero? 12:18
also
i'm not sure "\340\003a" is really a good name for a repr 12:19
:-p 12:21
jnthn WHO may legit be zero 12:23
No, tht does not look like a valid RER name :P
brrt could it be we're really looking at something other than MVMObject? 12:26
jnthn Maybe
You could cast it to an MVMStable 12:27
brrt hmm let's try that
jnthn Did you get this out of a spesh slot, by any chance?
Those are MVMCollectable *, meaning you might get an MVMObject * or an MVMSTable *.
In the case of th emethod cache I *think* we use two slots
One for STable of the type we've cached the result for
And one for the method result
I mean sp_findmethod here 12:28
brrt could be, difficulty is that it seems to be a returned object 12:31
nah, doesn't look like a STable
jnthn OK
brrt basically the whole thing is 0 12:32
jnthn oh
brrt difficulty is that it doesn't actually crash in the JITted frame
jnthn What makes the cache entries ooc?
brrt cache entreis?
jnthn Yeah
What installs the method? That's not JITted, right?
I mena, the whole body of sp_findmeth is in interp.c in master, iirc. 12:33
brrt yeah, i'm trying without sp_findmeth first 12:34
just findmeth and findmeth_s 12:35
jnthn ah
Are yo uhandle the invokey case of these two correctly?
Well, these 3 including sp_findmeth I guess... 12:36
brrt well, they are noted invokish, yes
and the log shows a invokish guard is compiled, too
12:50 woolfy joined 12:51 lizmat_ joined
brrt why doesn't my test script just ... break 12:59
:-( 13:03
13:15 avuserow joined, TimToady joined, japhb joined
brrt $?FOO variables, what kind of variables are these? 13:17
[Coke] $?foo compiler hint variable 13:18
jnthn Just compile as lexicals iirc 13:19
dalek arVM/moar-jit: 109b117 | (Bart Wiegmans)++ | / (6 files):
Move repr id checks to primitives
 13:24
brrt hmmm 13:26
weird
brrt afk for a bit 14:05
14:57 btyler joined 15:30 ventica2 joined 15:32 ventica3 joined 16:06 ren1us joined 16:55 klaas-janstol joined
dalek arVM: a9906fa | jnthn++ | src/mast/compiler.c:
Don't hunt for outer frame index if it's cached.

This was, curiously enough, one of the biggest time sinks in the entire assembly of large things like CORE.setting.		 17:08
timotimo oh, interesting 17:17
18:04 lizmat joined
dalek arVM: a4b0381 | jnthn++ | src/ (5 files):
Add an int -> str cache for 0..^64.
 18:25
timotimo does now seem like a good time to look at what b0rks my branch with the lazy wval sc lexical initialization thinie? 18:28
(yes, that is the scientific term)
jnthn Hm
Well, seems to me like it's a good time for dinner, given I'm hungry 18:29
But yeah, I can take a look at that after dinner :)
Thanks for the reminder.
nwc10 m: say 6.068e+01/6.1583e+01; say 6.068e+01/6.597e+01 18:30
camelia rakudo-moar 3ad15f: OUTPUTĀ«0.985336862445805ā¤0.919812035773837ā¤Ā»
nwc10 so, ho hum, that's another 1.5% since the last time
and about 8% since a bit ago
which is about as useful as xkcd.com/363/
jnthn++ # making things faster
and that's the commit before the one you just pushed 18:31
TimToady wonders if the JIT is the right place to pick up a divmod optimization when we $x/$y, $x%$y with the same $x and $y 18:36
since some CPUs can do both of those at once
nwc10 does Perl 6 code end up doing it often? 18:37
I really have no good feel for this.
TimToady not very, but it's usually time critical when it happens in an algorithm that's more ambitious than decoding time 18:38
that is, in brute-force factoring algorithms 18:39
nwc10 even if the CPU can't do both at once, is it usually faster to do one of the two, and figure out the other using multiplication?
I fear that that's a bit of a stupid question.
TimToady could well be 18:40
nwc10 but I'm not sure how to make something that generalises well
both in terms of recognising what the programmer wanted to acchieve
and in terms of propagating that information down in a form that the CPU understands
and I am not jnthn - I have not been working on VMs 18:41
(I've been working on "legacy green field code", as someone on #london.pm termed it, and a spec that only appeared about 3 months after the project started)
[we] thank Big Brother for raising the chocolate ration to twenty grammes a week. 18:42
TimToady well, I'm just thinking of something like rosettacode.org/wiki/Count_in_factors#Perl_6 compared to the Python solution
since they just supply a divmod function outright, which I can argue both ways
of course, a JIT would probably handle only native ints 18:43
nwc10 I wonder if there's a python equivalent of grep.cpan.me to see how often the divmod function is used 18:44
google-- for canning codesearch
clearly that fits right in with "Googleā€™s mission is to organize the worldā€™s information and make it universally accessible and useful. " 18:45
sorry, that's an off topic grumble
although the on-topic part is that grep.cpan.me is built using the open source technology originally built for codesearch 18:46
I should go and investigate the sunset
18:53 brrt joined
TimToady well, tommath's mp_div() returns both quotient and remainder, so we should take advantage of that somehow 18:53
brrt TimToady: in fact, div and mod are one and the same op on x86 18:55
iirc, you stuff RAX with the number you want to divide
you extend rax to an octoword byc combining with rdx 18:56
and division stores the quotient in rax and the remainder in rdx 18:57
TimToady so we can JIT a divmod for natives, anyway 18:58
brrt yes
TimToady doesn't look like we currently take advantage of tommath's divmod semantics
brrt it could be something for spesh to do
div followed by mod of the same operands could be merged into divmod
which can have a naive implementation for the interpreter and a fast implementation for the JIT 18:59
in fact, i'd personaly recommend that to do on a whole lot of stuff
TimToady well, in the RC entry I showed, the mod happens first
brrt doesn't matter semantically :-)
TimToady with a take in between :) 19:00
nwc10 agree, hence my comment about "recognising what the programmer wanted to acchieve"
brrt in the original jit tree graph structure that i'd proposed, such situations could also be eliminated using common subexpression elimination
jnthn back
nwc10 you're still tormenting language implementors :-)
TimToady tormented myself for years, so I'm used to doing that :) 19:01
oops, viewpoint shift
brrt \o jnthn
curry today?
TimToady *himself, *he's
but I'd like to point out that such torment is why P5 still beats the pants off of P6 most of the time :) 19:02
brrt isn't sure why TimToady would be glad by that :-) 19:03
TimToady well, except for the bits about redesigning the language to be nearly unimplementable :)
jnthn brrt: Yes, at lunch time... But dinner was salad with falafel and fetaost
uh, feta cheese
brrt much approve
nwc10 are your fingers going native?
jnthn No, that's just what it said on the container it came out of... :) 19:04
nwc10 t/spec/S17-lowlevel/thread.rakudo.moar has SEGVed on me, but as it was an optimised build I have very little to go on 19:06
#0 0x00007f0f6c5009b6 in MVM_bytecode_finish_frame () from /home/nicholas/Sandpit/moar/lib/libmoar.so
...
#8 0x00007f0f6c0f4b6d in clone () from /lib64/libc.so.6
brrt jnthn, can i pick your brain a bit 19:07
jnthn nwc10: Yeah, I know about a race around there...so I've a good guess what that one is.
brrt: sure
brrt ok, i'm kind of stuck with the findmeth situation, as in, findmeth itself isn't obviously wrong - it's just an invokish c call at my point, and the calls to it seem to be quite correct 19:08
jnthn OK
How can I reproduce the issue here? 19:10
brrt so my suspicion is, this has to be somewhere else, but somewhere else is a rather large space
ehm... let's see what i've committed last
jnthn srcjitemit_x64.dasc(1426) : warning C4129: 'j' : unrecognized character escape sequence 19:11
srcjitemit_x64.dasc(1426) : warning C4129: 'e' : unrecognized character escape sequence
ffs :)
It doesn't escape the filename :)
brrt basically, open src/jit/graph.c, find the lines in jgb_consume_ins that deal with findmeth and findmeth_s
don't worry about that, that doesn't do anything
jnthn I know :)
Just warnings.
brrt you can re-run make dasm_all to have windows-compatible filenames and no warnings 19:12
and uncomment that
then, build core.setting - which should crash - or nqp - which should throw
i say should because it's been erratic
although it has also never been OK
jnthn BOOM SEGV 19:15
brrt \o/ 19:16
but why?
jnthn You'll have to give me a moment to get an unoptimized debug verison... :)
brrt :-) 19:18
nwc10 jnthn: OK, cool. Let me know if you want help when you're going to start trying to chase it down. I can't promise that I'll be available, but I'll try
jnthn OK, it's running under my fave debugger
nwc10: Yeah; I'll probably look tomorrow. Planning to look at some other threading/async things then
brrt: Well. We explode in decont... 19:19
brrt in decont?
not mine
(what's your favorite debugger then?)
jnthn In the CORE.setting explosion
The VS one
brrt hmm.. haven't figured out how to use VS in a reasonable way for moar, so i'm using windbg directly 19:20
jnthn bah, this memory is total bs
brrt well, that i see too 19:21
jnthn 0x0000000000a60258 0x0000000000bb0040 0x00000000007a0040 19:23
oops
brrt ehm?
jnthn m: say (0x0000000000a60258 - 0x00000000007a0040) < 4194304 19:25
camelia rakudo-moar 3ad15f: OUTPUTĀ«Trueā¤Ā»
jnthn hmmm
The pointer is into tospace.
brrt hmmm 19:26
jnthn Which is where we allocate
brrt so that'd be good
jnthn Yes.
Well
If it's wrong then it's basically an extremely outdated pointer.
If I'm seeing this right, it does especially suck in so far as it means we screwed more at least 2 GC runs ago. 19:28
s/more//
brrt that
is possible
but hopefully not very likely
jnthn I'm afraid it's the best hypothesis I have so far.
If we were one GC run out of date the pointer would be into fromspace 19:29
And invalid pointer in tospace likely means we flipped again
Also, it matches in another way: the error. This happens when we're lucky enough to land up on a valid object. However, it's a completely different one than expected.
brrt uhuh 19:30
ok, that's pretty bad
brrt bbiab
jnthn It is in a sense; otoh, we've a relatively small search space... 19:31
Provided MVM_JIT_DISABLE makes it work.
My first guess - I'll go audit the code now - is that at some point we're putting a pointer on the stack or into a CPU register. 19:32
And then doing something that causes an allocation.
And then we've a bad pointer.
Yes, disabling JIT seems to make stuff work.
nwc10 m: say 5.8165e+01/6.068e+01/6.1583e+01; say 5.8165e+01/6.597e+01 19:35
camelia rakudo-moar 3ad15f: OUTPUTĀ«0.0155652219810724ā¤0.881688646354403ā¤Ā»
nwc10 m: say 5.8165e+01/6.068e+01; say 5.8165e+01/6.597e+01
camelia rakudo-moar 3ad15f: OUTPUTĀ«0.958553065260382ā¤0.881688646354403ā¤Ā»
nwc10 OK, that's 4% less time from just the last MoarVM commit. If I got that right
jnthn Wow :) 19:38
nwc10 that's actually what I thought.
jnthn if (op == MVM_OP_gethow) { 19:39
| mov TMP1, STABLE:TMP1->HOW;
This one isn't The Problem, but it's A Problem now that HOW is lazily deserialized. But that'd just lead us to getting a NULL
timotimo i saw a segfault above involving bytecode_finish_frame 19:40
could that need a lock?
i mean ... we're updating something very close to the sc 19:41
rather than something that hangs off of the tc
shouldn't be surprising that that can race, eh?
jnthn Yes, it needs a lock
timotimo suggest a name and i'll implement it
sc->lazy_vivify_lock?
jnthn That one isn't about the SC; it's about frames 19:42
I'd hang a lock off the comp_unit
timotimo OK
jnthn comp_unit already has a lock for rare things
I think
timotimo i'll look
jnthn I'd just use that one and generalize its name
timotimo update_pools_mutex 19:43
so maybe just "update_mutex"?
jnthn yeah, that'll do
MVM_OP_sp_p6ogetvc_o is vulnerable 19:46
/* TMP1 now contains address of item */ # I think this should say TMP2, looking at the code 19:49
But the heart of the issue is 19:50
| callp &MVM_repr_clone;
This can allocate
And an allocation at this point would invalidate TMP1 and TMP2 19:51
Which are both on the stack
timotimo simply putting the lock before and unlock after the loop over the static lexicals when finishing the frame leads to a deadlock ... oh well
valgrind has some tool that helps with deadlocks, odesn't it? 19:52
jnthn It wants to be around the entire finish deserialize of the frame
timotimo OK
jnthn With a re-check immediately after taking the lock to make sure we don't re-do work another thread did before we did the check outside of lock
timotimo OK 19:53
it seems like we want a re-entrant lock instead or something like that? 19:55
or a second lock
finishing the frame could end up adding strings to the compunit or something, which wants to acquire the lock
jnthn I don't think that can happen 19:56
At least, I'd like to see the codepath where it does if you think so... :)
'cus I can't remember one
The only thing that adds strings etc is inline.c
and we can't be - in a given thread - inlining and deserializing a frame :)
19:57 colomon joined
timotimo OK 19:57
jnthn cvtsi2sd # such op name
timotimo gist.github.com/timo/87a3c075c59a2ff917fc - could this mean the lock got created in a "locked" state? 19:58
oooooh 19:59
jnthn ohhhh
Wow.
timotimo we're recursively forcing the vivification of things
jnthn Yes.
Wow.
timotimo due to dependencies
jnthn Right. I didn't realize that was possible :)
timotimo (this is in nqp, when building QRegex.nqp)
jnthn *nod*
Well, darn.
Well, let's replace it with an MoarVM reentrant mutex object then :) 20:00
Apart from I dunno if we actually have a type for that yet 20:01
So may need to do that in bootstrap.c
timotimo welp, this task just got a whole lot bigger, didn't it? 20:02
jnthn A little ;)
But hey, you can look for GC bugs in assembly code instead if you want to swap ;-) 20:03
timotimo hah
20:06 brrt joined
timotimo i don't really know where i could cargo-cult stuff from 20:09
jnthn timotimo: I think it sets up a conc queue type in bootstrap.c 20:10
brrt jnthn ; you're quite a hero right now :-)
lizmat brrt: fancy giving a talk about your work at the next Amsterdam.PM meeting ? 20:11
timotimo oke, i can look at that
brrt ehm... when will that be? but i wouldn't mind per se :-)
lizmat first Tuesday of the month 20:12
2 Sep
timotimo um .. is it really just adding a REPRId, create_stub_boot_type and meta_objectifier?
there's a reprid already 20:13
jnthn There's already a repr ID sure
The repr exists
Just not the type
And yes, it's those two plus of course a field to hold it
brrt jnthn: why would cloning invalidate the pointer to the object? 20:14
jnthn brrt: clone allocates a new object 20:15
brrt: That could trigger a GC
brrt: And the GC moves objects
brrt lizmat: i'd like to, but i'll have use public transport and get back the same evening
jnthn Note that in interp.c it actually takes evasive action to prevent against this.
brrt .... /me checks that out 20:16
differences between interp.c and JIT are the most common source of bugs
jnthn (basically, a re-fetch)
brrt nice instruction names, btw, huh :-)
jnthn Sorry if the comment there was too opaque :)
brrt especially as SSE is involved
uh... i have very probably read over that 20:17
brrt facepalms 20:18
timotimo :)
brrt no matter, i can do this 20:19
jnthn I *hope* this will be it. 20:20
brrt it's a bug for sure 20:21
and just the sheer quantity of objects allocated by the grammar makes it plausible that this could cause corruption
20:22 klaas-janstol joined
brrt i see that i can probably simplify sp_p6oget_ with conditional moves 20:23
(ARM has conditional everything, x86 has conditional moves, imho these are sufficient for 90% of the benefit)
but let's focus on bugfixing first 20:24
lizmat brrt: back to Groningen ?
brrt lizmat: yes :-), i'm not sure but it's likely i'll be studying again
lizmat :-)
seems the last train from Amsterdam CS to Groningen leaves at 23:37 20:26
but the most comfortable last would be 23:07 20:27
(arrival 01:23)
20:27 itz_ joined
lizmat so that should work out, I would think! 20:27
brrt yeah, seems fun :-) 20:28
jnthn brrt: Don't suppose you'll make YAPC::EU? :-)
brrt i haven't arranged anything yet, and my funding is a bit low for a hotel + flight, so no, i'm sorry 20:29
jnthn np, was just wondering.
I sadly won't be able to make your talk in Amsterdam. 20:30
(Got a $dayjob assignment far far away...) 20:31
brrt how far is far? 20:32
jnthn Wrong continent far. 20:33
brrt anyway, i think i'll be arround, though
oh
that's far :-)
pls don't blow up :-o 20:38
[Coke] jnthn: you ever come to the states for $dayjob?
brrt nope, much blowup 20:39
jnthn [Coke]: Rarely. That's happened once ever...
Other times were confs or vacation
bbi15 20:40
brrt see you in 15 then :-)
timotimo brrt: oh well :\ 20:41
brrt might be a bug in my fix though
:-) 20:42
it's a bug, in my fix 20:45
or, the fix made another bug apparant 20:47
timotimo at least we know how to move forward 20:52
brrt hmmmm 20:53
timotimo has a moarvm that doesn't immediately crash 20:54
brrt \o/ 20:56
how do you get that
timotimo er
that's with changing the uv_mutex to a MVMReentrantMutex
in the compunit
the segv nwc10 mentioned earlier is either not easily reproducible or fixed. 20:57
brrt that.. doesn't seem like it'll be the same as my bug 20:58
dalek arVM: ef00cc5 | (Timo Paulssen)++ | src/ (7 files):
compunit->update_mutex is now a MVMReentrantMutex.

There is also a BOOTReentrantMutex now.
timotimo no, definitely not.
^- nwc10, this ought to fix the segfault you saw earlier 20:59
brrt no nqp blowup so far.... much tension 21:01
FROGGS_ and again an NFA debug session takes place \o/ gist.github.com/FROGGS/e991e1b3bf8796d91b82 21:02
brrt nqp works, rakudo not yet 21:04
oh, small bug 21:06
timotimo only a small one? :3 21:07
brrt well... lets say i'm sure this bug is a small bug 21:08
the one i just fixed
that doesn't quite fix the rakudo crash yet, though
although maybe ASAN now shows us something 21:09
jnthn Does it crash in a different place in Rakudo now?
timotimo no push yet?
21:11 colomon joined
dalek arVM/moar-jit: c06f75e | (Bart Wiegmans)++ | src/jit/ (4 files):
Reload object and address in case of clone

  jnthn++ for pointing out that cloning might
allocate, which might invalidate our pointer. This seems to fix the NQP build, however the rakduo build of CORE.setting still crashes.		 21:11
brrt somethings wrong with my asan 21:17
obj is garbage, again 21:28
hmm 21:32
maybe checkout what create does and if i've implemented that already
jnthn Only sp_fastcreate so far 21:34
| callp &MVM_gc_allocate_zeroed;
That's called before anything else
So it looks correct
brrt hmmm
jnthn As in, you don't grab any GC-able objects before that.
brrt no 21:35
jnthn The patch for the other thing looks correct at first glance too. Hmm 21:37
cxreg anything already in, or thoughts towards, mvm similar to ruby 1.9+'s cow-friendly gc? 21:38
brrt what's a cow-friendly gc 21:39
timotimo it doesn't try to overwrite data in its "old" generations
or something like that
cxreg patshaughnessy.net/2012/3/23/why-yo...n-ruby-2-0
brrt despite my inherent interest in GC algorithm's, tl;dr :-) 21:41
cxreg it uses a bitmap for mark and sweep vs touching the object and triggering a copy-on-write
pretty simple; very effective 21:42
timotimo well, we would want to update pointers inside the objects
brrt i see
hmmm
timotimo so we'd have to replace them into our newer pages i guess
cxreg update the pointers of in-use objects during gc? 21:43
timotimo we have a semispace copying gc
that means young objects move back and forth between from- and tospace and then the two of those get switched
cxreg gotcha 21:44
jnthn Well, for the young generation
Second generation doesn't move
cxreg without something like it, forking is a lot more expensive 21:45
timotimo well, we have a concept for multithreading 21:46
we don't need to do the "prefork" thing
:P
cxreg so "don't fork, ever" is your genuine feedback?
timotimo nope 21:47
cxreg i just wanted to point smart people at a neat idea, hopefully it worked
jnthn cxreg: Read it
timotimo there's more to having the old objects in pages that we won't ever write over again and then having a bitmap tell us which pieces are still of interest to us 21:48
jnthn cxreg: Objects in the young generation moving is fairly irrelevant for the optimization, in that it's the long-lived ones you're interested in being able to share
timotimo since whenever an old object has a reference to a young object, that old object would have to be changed
cxreg jnthn: very likely true 21:49
jnthn cxreg: These days gen2 marks are handled by a bit in the object header. It should be feasible to move it out in the future to a bitmap.
cxreg: The math is easyish for a bitmap table since gen2 is arranged into fixed-size pages.
cxreg timotimo: perfection isn't really the goal, that might be alright. the odds of an old thing pointing to a new thing are maybe low-ish? 21:50
timotimo not sure
cxreg i'm sure it's profileable
jnthn (old -> new) the generational hypothesis assumes this is the rare case
timotimo fair enough
jnthn If it wasn't then generational GC wouldn't be worthwhile :) 21:51
What's curious is it started out as an observation about how most programs behave
And now is a performance rule for programmers writing in garbage collected languages. :)
timotimo that's true %)
cxreg generational gc you mean? heh. where did that originate? 21:52
brrt ok, so decont is actually necessary for the bug to show up
that's not totally surprising
timotimo don't we do decont all over the place?
jnthn cxreg: Hmm, good question. I don't know who wrote the first paper in generational GC. But I'd not be surprised if it was done before I was born. :) 21:53
Let's see if I can find out from my gc handbook... 21:54
Seems, perhaps unsurprisingly, it coulda originated with LISP folks :) 21:56
aha
brrt sleep & 21:57
jnthn I think www.cs.utexas.edu/users/mckinley/39...s/LH83.pdf may be it
brrt i'll.. go and debug further tomorrow
jnthn brrt: Yeah, I'll have a look again tomorrow too :)
timotimo i think i'll quick-and-dirty hack a bit of logging into moarvm's gc to see how much of the nursery is free after each minor collection
brrt thanks for your help :-) 21:58
i'm planning to change graph loging, btw
jnthn Or citeseerx.ist.psu.edu/viewdoc/downl...p;type=pdf
timotimo graph logging?
brrt yes, the contents of the jit log
baiscally, i can't really tell the difference easily between compilation with and without certain ops 21:59
jnthn cxreg: Anyway, long story short - no, we don't do the thing Ruby 2 does yet. However, bitmaps can have significant advantages for other reasons too.
brrt and what happens really often is that some old code path is triggered / misused in new ways.. and i need to find out where
brrt nods with regards to the bitmaps argument 22:00
jnthn cxreg: For example, we can avoid even *reading* objects that don't point to other objects.
Which could have significant benefits
brrt although bitfields in objects have their advantages too; i'm not sure how bitmaps and concurrent collection would go together
jnthn We could even go so far as segregating on both size and touchiness
brrt: Yeah, but concurrent collection is...well...argh. :) 22:01
brrt such fun, much amaze
jnthn brrt: It's certainly not a universal good.
brrt no
jnthn cxreg: Anyway, to conclude, I see no reason we can't implement such a thing. Thanks for bringing it up; I'd been considering bitmaps for the other reason I mentioned, but this is an extra bonus. 22:03
brrt now really afk
jnthn o/ brrt
22:03 brrt left
jnthn cxreg: Of course, I've had a Windows upbringing and so am more used to thinking in threads that processes. ;) 22:03
cxreg jnthn++ thank 22:08
thanks! :)
timotimo aaw 22:14
no more jit progress before i go to bed? :(
jnthn timotimo: Only if you patch it ;) 22:17
jnthn is too tired to do anything more worthwhile today 22:27
'night
cxreg embeddable mvm is still a todo, right? 22:37
yeah, the main README says so. ok cool 22:39
timotimo what does "embeddable" mean to you? 22:51
tadzik having a moarvm fakexecutable with the code bundled, I guess 22:55
22:56 lizmat joined
timotimo ah, that 22:58
that's not what i think of when i hear "embeddable"
either tadzik or froggs had a prototype a month or two ago
but there was still some problem, forgot what.
cxreg i don't think that describes what I meant 22:59
I'm talking about sticking moarvm inside something ala libperl
timotimo oh 23:00
cxreg github.com/MoarVM/MoarVM/blob/mast.../README.md references this
timotimo yeah, that's what i think of when i hear embeddable :)
i didn't see that it was tadzik who wrote that
you have the same color in my weechat :)
cxreg heh.
timotimo well, we currently have a shared library "libmoar.so" and a very thin frontend "moar" that can "only execute moarvm files" 23:01
so it's actually already exactly what you want
and we have made sure to not have any globals, so you can have multiple MVM instances in the same process
i kinda wish for some mechanism in mvm that would allow me to supply hooks to implement loading files 23:04
that way, it'd be easy to compile MVM in a setting like NativeClient where file access needs to be "special" in some kind of way 23:05
or with emscripten
maybe a define flag that kicks out all I/O things libuv has and that moarvm uses 23:07
sockets, for example
oh, the main point was to offer a stable API for embedding 23:08
we don't have that yet, "obviously"
23:14 klaas-janstol joined 23:16 colomon joined
timotimo i may be reading or calculating this wrong, but during nqp's compilation, each nursery collection seems to leave the new nursery at about 3/4 filled?! 23:19
timotimo double-checks the math 23:22
fprintf(stderr, "nursery collection left us at %d of %d\n", (char *)tc->nursery_alloc_limit - (char *)tc->nursery_alloc, (char *)tc->nursery_alloc_limit - (char *)tc->nursery_tospace); 23:23
this ought to be correct, i believe
we reset the nursery_tospace before that code
most collection in both nqp and rakudo look like this: nursery collection left us at 7604800 of 8388608 23:27
is it just that we have boatloads of long-lived objects?
that's also true for a custom script of mine 23:29
as in: an application that does stuff :P
ooooh 23:44
that's how much is *free*, not how much is *used*
well, that was a major derp 23:45
you can tell what time of day it is over here ...
23:55 colomon joined
timotimo seems like it never leaves more than 10% alive after a minor collection, usually about 5% 23:56
.o( doesn't mean i'm not for getting rid of more extremely-short-lived containers and such ) 23:58

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!