github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 3 August 2013.
diakopter jnthn: well, they compiled without error... 00:01
good sign I guess
jnthn o.O
wow :)
So we get an nqp.moarvm out? :) 00:03
'night 00:05
diakopter no 00:08
well
No registered operation handler for 'freshcoderef' 00:21
:)
bbiab
00:27 benabik joined
JimmyZ Good morning 01:37
01:47 colomon joined
benabik o/ JimmyZ 01:49
And good evening. :-)
diakopter hi :) 01:56
time to figure out what freshcoderef does
hm, can't copy the jvm implementation because it .. clones the staticref 01:58
but we can't do that in moarvm
JimmyZ diakopter: thanks for fixing nqp:splice, but compared pir code, there is a retrogress
JimmyZ hopes that is a step debugger for nqp 01:59
diakopter compared to pir code? 02:00
what regression
JimmyZ: ^
JimmyZ diakopter: 00096 splice loc_0_obj, loc_2_obj, loc_6_int, loc_8_int
00097 set loc_0_obj, loc_2_obj
generated pir code is not set op 02:01
I still think it lost $*WANT somewhere
s/not/no/ 02:02
diakopter hm, I'm not sure why it's setting 2 to 0
that seems wrong
but really I'd ignore it for now
02:03 ggoebel joined
JimmyZ yeah, I'm looking for a nqp step debuger 02:03
:P
diakopter wonders if TimToady would use Eclipse if there was awesome p6 tooling 02:06
JimmyZ or padre
diakopter: are you trying added some cool tools to Eclipse? 02:09
diakopter no
just musing.
JimmyZ :P 02:10
02:52 Alpha64 joined 04:07 harrow joined 04:35 harrow joined 04:49 birdwindupbird joined 04:58 crab2313 joined
JimmyZ diakopter: I found why, but I don't know how to fix it :( 05:05
diakopter: In nqp on parrot ,the compile_all_the_stmts methods gives a :want('v'), where in MoarVM, it doesn't 05:08
06:27 FROGGS joined
FROGGS JimmyZ: can you create an issue so that we don't forget about the real problem behind splice? 06:37
JimmyZ yes, maybe after moving back to NQP/src/vm/MoarVM 06:39
FROGGS yeah right, doesn't sound to happen far in the future from what I read in the backlog... 06:40
JimmyZ hehe 06:41
jnthn good moarning o 07:31
o/
JimmyZ good morning, jnthn 07:32
japhb o/ 07:46
jnthn japhb! \\o/ 07:47
Long time no see :)
japhb Long time no chat. :-)
jnthn How goes?
japhb How have you been?
jnthn Not bad. Had some nice vacation last week :)
japhb Jinx. :-)
jnthn hah
japhb Where did you go?
jnthn Switzerland 07:48
japhb Alps hiking?
jnthn Some hiking, some just looking on in awe :)
Managed to make it to a place where you could get some really good views of the aletsch glacier. 07:49
japhb Cool. I've always wanted to go glacier watching, but just haven't gotten around to it somehow. :-/ 07:50
So from reading planetsix, it sounds like Rakudo-JVM is doing pretty damn well. 07:51
How are things going in MoarVM land?
jnthn They're going, mostly thanks to the efforts of folks other than me. Didn't get NQP bootstrapped yet, but closing in on it... 07:52
Your bigint stuff was merged.
japhb \\o/
jnthn bbi10 07:53
japhb I assume then that you did whatever you needed to in the lower layers to unblock the remaining bigint work?
japhb has forgotten the details of that. :-(
Time to get some shut-eye. 07:56
bbitm &
diakopter FROGGS: the real problem? 08:02
FROGGS: I don't understand how my solution wouldn't also work 08:04
FROGGS diakopter: the real problem is that $*WANT should be defined and zero, but it is undef for some reason... if it would be zero it wouldnt try to box it to an obj
diakopter jnthn: ping
FROGGS diakopter: it works, like that worked what JimmyZ++ reverted (the commit I showed you), but it just hides the "real problem", no? 08:05
diakopter well it covers all the same cases, but whatevs, I'll push the other fix 08:07
jnthn: I need to ask you about some of these unimplemented coderef ops 08:09
some of them assume that staticframeinfo is a 6model object
(which it is on jvm)
so should it become that on moarvm? or do u have some other way of storing a distinct mvmcode object on each staticframeinfo 08:10
...
or... am I misunderstanding greatly
FROGGS: actually, I suspect it needs both fixes 08:12
FROGGS yeah, that sounds about right 08:13
jnthn diakopter: staticframeinfo isn't a 6model object on the JVM, but it is a plain old JVM object and will get GC'd at the appropriate point 08:17
I agree we need to do something more interesting on Moar. When I was last doing GC bits, I did start considering if compunit and staticframe should be collectable things. 08:18
For one because we then can just put them under the generational scheme and never have to consider them in nursery scans in the common case. 08:19
I guess the other question, though, is exactly what freshcoderef wants to have unique to itself... 08:20
diakopter right 08:21
(was what I was pondering)
er 08:22
staticcodeinfo is a 6model object on the jvm
did sorear make it one without you noticing? 08:23
jnthn public class StaticCodeInfo implements Cloneable { 08:24
...don't see it inheriting from SixModelObject ?
diakopter oh hm.
how in the world..
(..did I think that?)
anyway, ok 08:25
yes, we'll leak memory with throwaway evals
without GC'ing those... *and* their bytecode 08:26
JimmyZ diakopter: FROGGS the real problem is irclog.perlgeek.de/moarvm/2013-08-05#i_7410591
diakopter compilation units
yes yes I fixed it
will push it with the rest of these
JimmyZ ah, diakopter++
diakopter jnthn: actually, the compilation unit also needs collectable too.. 08:28
jnthn aye
diakopter jnthn: we can make them p6opaque if you want... just with structs to cast them to also. ;) 08:29
well, they're pretty complex and large, nm
:D
08:59 crab2313 joined
JimmyZ jnthn: please take a look at readlineintfh2 branch when you have time :P 09:02
10:43 flussence_ joined 10:46 japhb_ joined 11:07 crab2313 joined 11:55 colomon joined
JimmyZ Good evening 12:27
FROGGS hi JimmyZ
12:30 hoelzro joined
JimmyZ hi FROGGS 12:33
FROGGS gah, it is 2:30pm and I'm almost falling asleep 12:34
tadzik I've had this since 9 :/ 12:35
FROGGS :/
12:45 crab2313 joined 12:49 crab2313_ joined 14:43 bronco_creek joined 15:12 Alpha64 joined
diakopter jnthn: howdy 15:29
jnthn o/ diakopter 15:30
diakopter jnthn: fell asleep while coding last night.. 15:31
jnthn diakopter: Did you dream about the code? 15:32
diakopter it dreamt about me
jnthn :P
FROGGS imagines diakopter only covered by code snippets 15:33
diakopter O_O 15:34
opaque code snippets, I hope. hahaha. 15:35
FROGGS *g*
jnthn doesn't say anything about the opacity of diakopter's code :P 15:36
16:09 FROGGS joined
FROGGS ahhh, home sweet home 16:17
diakopter jnthn: lololol 16:23
jnthn: so... what's the verdict on repr-ifying staticinfo and compunit 16:40
I'm glad to do it; I know what's needed
(it's holding up me implementing these 4 related ops) 16:41
personally I don't know why a staticinfo needs to hold onto a code object.. if there's already a mvmcode that's holding another mvmcode and marked static 16:42
jnthn diakopter: I had at least the compunit bit of it on my todo list for a while, but never got there. :)
diakopter: I think it makes sense to go that way with staticinfo too 16:43
diakopter: Especially after noting how having to walk them all every nursery collect gets painful once you end up with a lot of stuff loaded.
diakopter k 16:45
well, that's the easy answer to my last question I guess :) 16:48
(just copy how jvm does it)
(I don't mean to detract from easy answers, btw) 16:49
jnthn The main thing I want to avoid is having every single frame contribute to GC overhead, which is why those are ref-counted. 16:51
The frame pool means we avoid allocating at all in steady state.
Making comp units and static code info GC-able doesn't hurt here, and could indeed help by making us consider them less.
diakopter could, yeah, hrm 16:52
jnthn: thanks for your answers. on another note, could you write out (in a gh issue perhaps?) the things remaining with the GC so ... more than 1 person remembers them :) 16:53
I think there were 2 medium-sized issues
16:53 Alpha64 left
diakopter I feel prepared to tackle GC debugging/fleshing at some point this week 16:53
gh=github, not greenhopper. ;) 16:54
jnthn diakopter: Well, my main problem was not quite knowing what was wrong.
diakopter: I can dig up my test case that hit issues for others to do some debugging on though. :)
diakopter oh, that one 16:55
I was thinking of the permgen links to nursery things
jnthn Oh, I already spent some time on that :) 16:56
diakopter I know; I just wanted to know where you left off and what was left 16:58
jnthn I *thought* I'd dealt with those problems already. 16:59
diakopter ohhh 17:00
didn't realize
I thought that was still outstanding
jnthn++ 17:05
jnthn*=jnthn
jnthn: one of the threads tests still hangs for me on windows 17:16
does it for you?
FROGGS it fails on linux sometimes 17:17
jnthn diakopter: It's inconsistent. 17:19
It tends to apss at the moment
But I did see it fail occasionally in the past
diakopter FROGGS: which test 17:22
on linux
test 5 hangs for me on windows 17:23
FROGGS diakopter: nqp-cc/t/moar/threads.t
diakopter which test in there
FROGGS hmmm, no idea
diakopter can you run it?
nqp file 17:24
FROGGS I'm currently recompiling to do that, yes 17:25
diakopter: it doesnt output anything except "Can't free STables in gen2 GC yet" 17:32
diakopter which doesn't output anything? 17:33
test 1?
it doesn't even say 1..6 ?
FROGGS diakopter: here gist.github.com/FROGGS/3db2bca4a188a2c1b592 17:53
test number 6 fails
diakopter k 17:54
yoleaux 17:37Z <nsh> diakopter: WATCH OUT RIGHT ANGLES ARE VENTING SODOM
17:37Z <dpk> diakopter: 6.2 i think
diakopter wat. 17:55
FROGGS ?
diakopter jnthn: can I store the mast types in the hllconfig? 18:17
jnthn: or just make separate getter/setter ops 18:18
jnthn: hm, this increases the places that need MVMROOT... :/ 18:33
18:34 crab2313 joined 18:36 benabik joined
diakopter jnthn: .... dramatically] 18:37
ah well..
jnthn diakopter: No, the types should be passed in a hash to the eval op, I think. 18:39
diakopter hm, ok
jnthn nqp::mvmcompile($tree, nqp::hash('lexical', MAST::Lexical, ... )) 18:40
diakopter jnthn: that returns a compilation unit? 18:41
or a code of the entry point? 18:42
jnthn Probably a compilation unit...on JVM I had two ops, one to produce an in-memory thing like eval, one that spat the bytecode out to disk 18:43
diakopter k
.. adding a BOOTStaticFrame and BOOTCompUnit ..
.. that was far easier since I macroized those... 18:48
jnthn: and a jillion more MVM_ASSIGN_REFs 19:27
jnthn diakopter: yes, we may be missing some of those :) 19:28
diakopter: Where are you needing more? :)
diakopter lolol
all over... tons of places in bytecode.c and frame.c
(because of promoting, I mean demoting, staticframe and compunit to collectables) 19:29
jnthn ah :) 19:30
yeah
diakopter I'm trying to be rigorous and careful
I'm sure I'll miss some
jnthn One day, I'll have time to do a code review of all the things :)
FROGGS ALL TEH THINGS
diakopter haha
masak demoting them to collectables? you mean like Pokemon? :P 19:32
diakopter get back in your ball 19:33
jnthn And the GC is having a peek-at-you? :P
diakopter wow.
jnthn: ok, tougher question.. make STables GC'able? (yes, they can be circular!) also. SerializationContexts? 19:36
oh wait, SCs already are... duh. 19:37
jnthn: so... STables? :D 19:38
btw, I suggested to rurban he implement man_or_boy in potion for p2... b/c with its JIT I don't think it's possible 19:40
arnsholt Why wouldn't it be possible? 19:42
masak jnthn: in Soviet Russia, the GC is having a peek at you.
diakopter arnsholt: b/c it's really luajit underneath, which uses the cpu stack for the callstack
arnsholt Ah, right 19:43
diakopter and man_or_boy gets hundreds of thousands of ... yeah
er
it's not luajit.
<- forgot
it's another jit.. but works similarly
jnthn diakopter: STables already are 19:44
diakopter: They're not MVMObject, but they're MVMCollectable 19:45
diakopter yeah.. I guess I meant, .. ok.
nm
<- especially stupid today
jnthn ;)
diakopter well, that's a large diff 19:51
FROGGS does `git status` tell you you did a >80% rewrite of MoarVM? 19:55
diakopter hee 19:58
30 files modified 19:59
so far
jnthn: the self-replacing stubs in the regex engine are interesting 20:00
reminds me of the speedup I did for moose that cut startup time dramatically.. but a patch they haven't yet accepted
jnthn: I just realized the current atomic counter isn't sufficient for tracking static frames' frame pool caches on each threadcontext, since we'll now be freeing them.. so we'll need a freelist also 20:23
er, instead 20:24
.. which is fine
jnthn hm, yes 20:26
Though, maybe we don't care to cache such dynamic frames
Hm, or we do. I dunno, I'd have to dig a bit and I'm already digging a bunch of other things :)
diakopter I dunno. std, for instance, uses enormous amounts of eval
jnthn ah, I see 20:27
Yeah...you're right
20:27 cognominal joined
diakopter jnthn: you know... we could still cache MVMFrames of the same sizes as long as we allocated them in 2gen first.. eliminating the GC pressure just as much as currently 20:30
er, GC overhead, as you said 20:31
.. and pressure
FROGGS I think there are no other non-latin chars left 20:34
ww 20:35
20:36 colomon joined
diakopter jnthn: what do I do with teh head_compunit list on instance? :S 20:38
put a lock on it and make it doubly-linked?
jnthn diakopter: Well, additions can go at the HEAD and be CAS'd 20:42
diakopter oh, I guess removals are via the gc, so naturally locked
jnthn Removals...I guess those are when it's GC'd and we dknow we're in "stop the world" situation there.
diakopter <- wins 20:43
jnthn yeah, but you're not refactoring Rakudo module loading to try and load Java libs at the same time :P
diakopter sigh 20:44
jnthn: MVM_ASSIGN_REF(tc, sc, ((MVMSerializationContext *)sc)->body->handle, handle); 20:56
body.handle?
yes, surely 20:57
jnthn diakopter: No, it's held at a level of indirection. 20:58
diakopter: The SCs are stored in a kind of "weak hash" arrangement.
diakopter struct _MVMString *handle
jnthn The -> is about body, not handle. 20:59
diakopter ->body->handle
jnthn Right.
diakopter but body's not a pointer.. oh, or is it?
jnthn Serialization contexts hold their "body" a level of indirection off
diakopter oh, it is.
jnthn Unlike other things.
diakopter heh, oh.
that's wee-uhd
jnthn I know. 21:00
jnthn can hack too :P
diakopter :D
21:03 Alpha64 joined
diakopter jnthn: actually.. 21:18
I can't use MVM_ASSIGN_REF when assigning a static frame to a member of MVMFrame... so now what 21:19
jnthn diakopter: It's just a normal C assignment.
The active frames we have always need to be walked in a GC run.
At the moment we "go hunting" for them, but I've pondered just keeping a per-thread double-linked-list. 21:20
Given that they are cached per-thread anyway
diakopter hrm
jnthn An the GC just traverses that to find roots.
*And
That would be quite a cleanup.
diakopter ?
what would be a cleanup
jnthn Cleanup ain't quite the word I wanted 21:21
Performance win, perhaps, though.
diakopter what would
jnthn At the moment, anything that refs a frame has to be considered in ever collection.
*every
When an object that references an MVMFrame is promoted to gen2, it's also put into the "points to nursery"
As it may well do os.
*so
diakopter ok 21:22
jnthn grep for refs_frame, iirc
diakopter seen it
jnthn: you didn't comment on my comment about mvmframe collectable 21:25
jnthn Yeah. The problem is one of lifetime. 21:27
diakopter why?
jnthn The frame refcounting means we know as soon as a frame dies.
Which may be very soon.
And can recyle it right away, maybe for an immediate next call.
Meaning we may never end up with more than one of them allocated and being re-used. 21:28
If we do them with the GC, we can't return them to the cache until the next collect.
Which could be in quite a while if we have a 2 meg nursery size, for example.
diakopter yeah, I guess you wouldn't want to refcount *and* gc... 21:29
21:30 Alpha64 left
jnthn aye, that's most likely a path to insanity 21:31
diakopter jnthn: hm, seems we need a version of MVM_ASSIGN_REF that does CAS 21:35
..or not 22:22
.. but at least now I know how to do it if we do need it
jnthn :)
diakopter played 5 games of ping pong in the interim 22:23
23:03 nwc10 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!