Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-16

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:21 btyler joined #moarvm
01:28 FROGGS__ joined #moarvm
01:49 ilbot3 joined #moarvm
01:49 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:15 cognominal joined #moarvm
05:45 cognominal joined #moarvm
06:08 sergot o/
06:49 brrt joined #moarvm
06:52 brrt \o
07:03 odc joined #moarvm
07:09 brrt hmm, how would i trigger a decont?
07:20 brrt hmm, i've a failing test case
07:20 brrt yay
07:20 brrt (better yet: an isolated failing test case)
07:23 brrt as in, it's not failing in the compiler but in the script
07:34 brrt now, why does this fail
07:36 brrt interestingly, it seems that unless_o Just Works
07:46 FROGGS__ well, that's good to hear :o)
07:49 brrt emphasis on /seems/ :-)
07:57 brrt ok, confusing stuff halfway through the frame
08:43 klaas-janstol joined #moarvm
09:02 brrt joined #moarvm
09:02 daxim joined #moarvm
09:07 FROGGS[mobile] joined #moarvm
09:11 brrt it almost seems the locals are wrong
09:15 jnthn It's not that an exception somehow got thrown at some point?
09:16 jnthn I realized, though, that throws from C-land actually lngjmp back into the interpreter...
09:18 brrt frankly, though, i have no idea
09:28 dalek MoarVM/latin2: 4bb41be | (Tobias Leich)++ | / (5 files):
09:28 dalek MoarVM/latin2: stub latin2 support
09:28 dalek MoarVM/latin2: review: https://github.com/MoarVM/MoarVM/commit/4bb41be72b
09:34 teodozjan joined #moarvm
09:53 brrt joined #moarvm
10:54 carlin joined #moarvm
11:15 brrt joined #moarvm
11:16 jnthn brrt: Any luck?
11:16 brrt not yet
11:17 brrt interestingly, if i remove the branch in the nqp file, the script works well
11:18 jnthn Can you isolate the issue to the JITting of a particular op?
11:18 jnthn Could it be to do with the "did it invoke" code?
11:18 brrt likely
11:22 brrt hmm check this out: https://github.com/MoarVM/MoarVM/blob/moar-jit/foo.nqp#L24
11:22 brrt change that 100 to 50,  and the script outputs 50
11:25 jnthn wtf...
11:26 brrt yes
11:38 jnthn | is_type_object TMP5;
11:38 jnthn // object is type object (not concrete)
11:38 jnthn | jz >1;
11:38 jnthn That does jump if zero?
11:38 brrt yes
11:39 jnthn We want to *not* decont if it's a type object.
11:39 brrt letmesee
11:39 brrt and that seems to be what it does?
11:40 brrt oh, right
11:40 brrt ugh, much confuse
11:40 brrt let's fix that and see what it does
11:40 brrt (i'm afraid not much in this case)
11:40 jnthn Well, is_type_object sounds like it will put non-zero if it *is* a type object... :)
11:41 brrt right
11:41 brrt that's precisely what it ought to do
11:44 jnthn errands, bbi15
11:45 brrt see you in a bit, then :-)
12:06 jnap joined #moarvm
12:06 * jnthn back
12:19 carlin joined #moarvm
12:26 brrt joined #moarvm
12:27 * brrt too
12:30 dalek MoarVM/moar-jit: c69b835 | (Bart Wiegmans)++ | src/jit/ (5 files):
12:30 dalek MoarVM/moar-jit: Fix concreteness check in decont
12:30 dalek MoarVM/moar-jit:
12:30 dalek MoarVM/moar-jit: jnthn++ for pointing it out
12:30 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/c69b835ade
12:36 brrt it's kind of hard to breakpoint smrt_numify
12:37 brrt and to be honest.. it's kind of unlikely that it's really the problem
12:39 brrt because /without/ if_o and unless_o It Just Works
12:39 timotimo damn :(
12:40 brrt yes
12:41 timotimo but decont works fine?
12:41 brrt who knows?
12:41 brrt it's kind of hard to test without an explicit test case
12:41 timotimo ah, fair enough
12:42 timotimo could always go back to writing your frames with the mast compiler ;)
12:42 brrt possibly
12:44 brrt ok, smrt_numify is broken, that's for sure
12:44 brrt somehow
12:46 jnthn Is it not missing the control_invokish?
12:47 jnthn oh, that's done automatically
12:47 brrt it ought to be, and it doesn't seem to be missing
12:51 brrt somehow, it seems as if the Bool() frame walks all over the bar frame
13:01 jnthn I guess the Bool frame is JITted too?
13:03 brrt doesn't seem to be
13:03 brrt takes param_rp_o
13:03 brrt anyway, i'm in the breakpoint as we speak
13:06 * brrt wonders whether it has anything to do with special_return
13:07 jnthn I don't immediately see an issue there; you're using the normal return code-path that triggers that...
13:08 * brrt is still stepping through the code
13:32 * brrt thinks this is exhausting
13:33 jnthn Was stepping through the code not informative?
13:34 brrt hmm... yes, in the sense that 'all appears to be normal'
13:34 timotimo the perl6.org/compilers/features matrix still lists Promises and Supplies as "no time based", i can fix that to be a green + now, right?
13:35 jnthn Yeah, time-based stuff works on Moar now
13:37 timotimo i knew most of it did, i wasn't sure if we're at 100%
13:37 timotimo that's good to know
13:37 timotimo i'll update it later today. AFK for an unknown amount of time now.
13:49 brrt no progress yet :-(
13:51 jnthn aww :(
13:51 jnthn Hard problem is hard.
13:52 btyler joined #moarvm
14:46 brrt very hard indeed
14:53 btyler joined #moarvm
15:00 raiph joined #moarvm
15:01 brrt :-(
15:02 jnthn brrt: Is that "argh now I know why it's wrong", or "argh I can't figure it out"?
15:02 brrt argh can't figure it out
15:02 brrt *nothing* seems wrong
15:03 brrt except that somehow, the 50 in the value is the value that is printed by nqp::say
15:03 jnap joined #moarvm
15:07 jnthn Is nqp::say one of the ops we JIT?
15:07 brrt yes, and i'm in the breakpoint
15:07 brrt as we speak
15:08 jnthn If you look at the spesh log, does the register passed to the say correspond to a register that 50 is put into inside of Bool?
15:09 brrt hmm that'd be weir
15:09 brrt d
15:10 brrt i'll check
15:10 jnthn Well, if we think it might be using the wrong registers, that might confirm or break the hypothesis.
15:11 brrt very well :-)
15:31 brrt it seems.. the Bool() frame is never speshed
15:32 jnthn Oh?
15:32 brrt yes
15:32 jnthn That's odd given how often it's called.
15:33 jnthn If you can get at it, what does sf->body.invocations have in it?
15:33 brrt however... it is indeed the case that the 50.0 constant is in the 4th register
15:33 brrt so that's got to be worth something
15:33 brrt (the say is also in the 4th register)
15:33 jnthn Also you put an nqp::say in the Bool method, does it get used?
15:33 brrt yes
15:33 jnthn s/get used/get said/
15:34 jnthn OK
15:34 brrt :'-(
15:34 jnthn Is it "never spesh'd" or "never finishes specialization"?
15:35 jnthn (There is the initialization of specialization which inserts logging, then the actual final spesh after logging which is triggered at frame exit time)
15:35 brrt spesh doesn't seem to see it
15:35 brrt the name of Bool() never comes up in the spesh log
15:35 brrt anyway, i'll see if i can get at the invocations nr
15:35 jnthn Oh...
15:35 jnthn I think I can guess
15:36 jnthn I'll bet the callsite doesn't have the "is interned" flag set.
15:36 brrt that could well be, since it is a constant
15:37 brrt defined at src/core/coerce.c line 10
15:37 jnthn OK, so it's something about returning
15:38 brrt actually, returning is what seems to be fine
15:38 jnthn if (MVM_jit_enter_code(tc, cu, tc->cur_frame->spesh_cand->jitcode)) {
15:38 jnthn Do we return 0 there?
15:39 jnthn So we aren't actually forcing the just-invoked frame to return?
15:39 brrt good question
15:39 jnthn | mov RV, 1;
15:39 jnthn | jmp ->out;
15:39 jnthn Is what I see for  MVM_JIT_CONTROL_INVOKISH
15:39 jnthn Which'd cause it to attempt the return, *if* I'm reading this all correctly.
15:40 brrt well, no, because MVM_jit_enter switches this all arround
15:40 brrt good fun, huh
15:40 * brrt agrees this is confusing and will change it arround
15:40 brrt but fwiw, the interpreted frame is actually invoked and i can step through it
15:42 brrt invocations is 14, spesh_threshold is 10
15:45 jnthn OK, and is tc->cur_frame->static_info->body.name pointing to a string Bool?
15:45 jnthn Where is the code that handles returning into JITted stuff, ooc?
15:54 brrt i'll look at the first thing first
15:55 brrt hmm... how to print the MVMString in gdb?
15:56 brrt yes
15:56 brrt (you can call a function in gdb, apparantly)
15:56 jnthn Look inside of the codepoints buffer
15:56 jnthn ah, nice :)
15:56 jnthn in VS too
15:56 timotimo brrt: my python extension for moar can print MVMString for you
15:56 jnthn OK, then what happens if you trace things back to after the return and when you're in the JITted code again, about the print the 50?
15:57 * brrt will have to see how that's done
15:57 brrt timotimo - how to use that extension?
15:57 brrt i can breakpoint MVM_string_say, i think
15:57 timotimo tools/moar-gdb.py  ← read the beginning of that
15:58 brrt thanks :-)
16:01 brrt the most mysterious thing of all is that the work buffer of the JIT frame is /not/ the same as the work buffer of the interpreted frame
16:01 brrt so how can a value in one end up in the other
16:03 timotimo oh, moar-gdb.py may need changes due to the strref?
16:03 jnthn Question: can this be reproduced with if nqp::istrue($x) instead of if $x ?
16:03 jnthn Uh, or whatever the variable was called :)
16:04 brrt hmm
16:04 brrt i'll try
16:05 brrt actually, that'll give us another bug
16:05 brrt ain't that fun
16:06 carlin -Ofun :)
16:08 brrt -Omadness :-)
16:10 brrt dinner &
16:10 brrt left #moarvm
16:38 btyler joined #moarvm
17:12 btyler joined #moarvm
17:29 tgt joined #moarvm
17:38 brrt joined #moarvm
17:39 brrt ok, i'm kind of out-of-strategies right now
17:42 FROGGS__ :/
17:43 timotimo :(
17:43 FROGGS__ brrt: you tried valgrind?
17:43 brrt good idea
17:43 brrt let's try that out :-)
17:43 FROGGS__ :o)
17:44 FROGGS__ I hope it shows something
17:44 brrt well, no :-)
17:44 FROGGS__ :/
17:44 brrt can't always get what you want
17:44 FROGGS__ yeah, sadly
17:50 rurban gdb stepi
17:51 rurban and disassemble /r %rip
17:56 * brrt has tried that, and everything seems correct
17:57 rurban then I would suspect one of your nonvolatile registers
18:00 brrt well... that's possible of course
18:02 brrt what type is type 2?
18:05 brrt ok, hmm
18:05 brrt i think i'm getting at something now
18:07 timotimo cool! :)
18:11 brrt or rather, a case wherein we /should/ jump out but don't, or something like that
18:12 brrt i.e. the current frame isn't restored properly, or something like that
18:23 jnthn ooh, mail tells me I have 2 accepted talks at YAPC::EU.
18:23 timotimo \o/
18:23 timotimo congrats
18:23 timotimo looking forward to seeing the recordings :)
18:25 brrt congrats indeed
18:25 brrt very nice
18:26 FROGGS__ jnthn: you do a talk about the performance improvement over the last year... what is the other talk about?
18:26 jnthn async things
18:26 * FROGGS__ .oO( "Implement NFG during this talk" )
18:26 FROGGS__ ahh
18:26 FROGGS__ :o)
18:27 jnthn Implement NFG in a *talk*? I'm Not F**king God! :P
18:27 brrt sure you are
18:28 nwc10 God would need a full talk, whereas Chuck Norris would only need a lightning talk?
18:32 timotimo god would write the code to disk by striking it with lightning.
18:33 timotimo and the thunder would sound like speech.
18:33 FROGGS__ jnthn: well, you could stub some parts the day before the talk, so the presentation would be smooth :P
18:37 carlin joined #moarvm
18:39 tgt Hi. I just received the error "Heap corruption detected: pointer 0x10d4817c8 to past fromspace". GC issue?
18:40 timotimo ooooh
18:40 timotimo please do paste your code
18:41 timotimo something's not using the GC right, possibly
18:42 timotimo jnthn: did you see #122306 just now? is probably the same underlying problem that someone recently showed happening with a for loop and the LAST phaser behaving differently with "is copy" and "is rw"
18:42 synopsebot Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=122306
18:42 tgt https://gist.github.com/tgt/07bf0b5d9dcaf32760e8
18:43 tgt Reading a file with 540 lines.
18:43 timotimo oh wow, that's very well golfed!
18:46 brrt command_eval, where should that be?
18:47 timotimo t/roast/lib?
18:47 timotimo er, t/spec/lib?
18:47 brrt hmm no, its directly under command_line
18:47 brrt this .. is weird
18:47 jnthn brrt: src/HLL/Compiler.nqp if you are looking for where it's impl'd.
18:47 timotimo oh!
18:48 brrt i just skipped remove_one_frame, but i suspect something really funky has just happened
18:48 timotimo i was quite confused there for a moment :)
18:48 timotimo i think i thought of "eval_ok" or something
18:49 tgt Is there a bug tracker I should submit the bug to?
18:49 brrt one moment, my current frame's caller was Bool(), and after remove_one_frame, it's command_eval
18:49 brrt hmm
18:49 jnthn tgt: http://github.com/MoarVM/MoarVM/ has an issue tracker
18:49 brrt takehandlerresult
18:50 jnthn brrt: Hm, that'd mean an exception was thrown somewhere...
18:50 brrt ok, weird
18:51 jnthn Try breakpoinging MVM_exception_throw_adhoc
18:55 brrt good idea :-)
18:56 tgt Issue added.
18:58 jnthn tgt: thanks
19:00 FROGGS__ tgt: I'd just need a text file that has >540 lines?
19:00 FROGGS__ does line length matter?
19:01 tgt I just had incrementing numbers. I'm using OS X. Perhaps it varies by platform.
19:01 FROGGS__ ahh, okay
19:04 FROGGS__ gist/07bf0b5d9dcaf32760e8$ perl6-m -e '(^1000)>>.say' | perl6-m gistfile1.p6
19:04 FROGGS__ Heap corruption detected: pointer 0x7f1bed39ef20 to past fromspace
19:07 brrt *ahum* istrue is invokish, istrue_s is not
19:07 brrt that fixes that part, at the very least
19:08 timotimo aaaah
19:09 timotimo which part gets fixed?
19:09 jnthn istrue_s is way simpler, yes.
19:09 dalek MoarVM/moar-jit: def5e98 | (Bart Wiegmans)++ | / (4 files):
19:09 dalek MoarVM/moar-jit: Istrue is invokish, while istrue_s is not
19:09 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/def5e98fde
19:10 brrt the part wherein the invokish istrue failed because it wasn't invokish-guarded
19:10 jnthn FROGGS__: The standard trick for trying to isolate those is reducing MVM_NURSERY_SIZE a bunch
19:10 jnthn brrt: Grrr...I shoulda spotted that when I read the patch :/
19:11 brrt not your fault
19:11 brrt i was stepping through the asm, and suddenly i thought 'hey, that's weird, i'm at the gc sync point already'
19:11 FROGGS__ jnthn: the I'll get near the spot that causes it?
19:12 jnthn FROGGS__: yes
19:15 timotimo tgt: in any case, thank you for the report!
19:17 FROGGS__ jnthn: is the nursory size too small when I get a core dump?
19:17 FROGGS__ nursery*
19:18 tgt No problem :)
19:18 jnthn FROGGS__: Yes :P
19:18 jnthn Well
19:18 jnthn Or you found the problem
19:19 jnthn You can get it at 1024 and all should work
19:19 jnthn I had it at that last night
19:28 brrt problems around smart_numify persist
19:29 jnthn Ah, so there were two bugs...
19:29 brrt obviously :-)
19:31 brrt at least two bugs, even
19:31 brrt that said
19:31 brrt i can't really find a fault wrt to unless_o and if_o
19:31 brrt they Just Work, even though it is the Bool() frame that seems to override the current frame
19:32 brrt i'll make this so much worse for all of us right now
19:33 brrt because smrt_numify /does/ work w/o unless_o
19:33 jnthn o.O
19:33 jnthn It's not some weird stateful thing going on?
19:34 jnthn What happens if you have multiple smrt_numify or multiple if_o in a frame?
19:34 brrt good question
19:35 brrt hahahaha
19:35 brrt well, it is actually probably a weird / stateful thing
19:36 jnthn oh my... :)
19:36 brrt because in fact, the second time i call smrt_numify, i get a zero where a number should be
19:36 jnthn Well, there we go then.
19:36 * brrt now really suspects some kind of frame corruption
19:37 jnthn So, diff the assembly we produce for the two cases to make sure the weird stateful thing isn't in the code-gen, and actually is at runtime?
19:37 brrt good idea
19:37 * jnthn hopes he's not being too much of a backseat debugger :)
19:37 jnthn "No, turn LEFT at the breakpoint!"
19:37 FROGGS__ "Are we there yet?"
19:38 jnthn "Can we stop to get icecream?"
19:38 FROGGS__ "I need a toilet!" :P
19:38 brrt no, you're being a good help :-)
19:39 brrt fascinating
19:39 FROGGS__ O.o
19:39 brrt (what is fascinating, you ask? i'll tell, oh boy i'll tell)
19:40 jnthn Did anybody else, as a kid, see "TO LET" signs on buildings up for rent and want to grafiti in an "I"? :)
19:40 brrt no
19:40 brrt but mostly because of non-native english, i think
19:40 jnthn yes. :)
19:40 brrt very few 'to let' signs here
19:40 jnthn Right
19:40 jnthn Te huur or something, right?
19:40 brrt right
19:40 brrt zu mietung, i believe, in german
19:40 lizmat zu vermieten
19:40 * jnthn hopes he actually got the word for "rent" and not a similar sounding one... :)
19:41 brrt yes, you got the right word
19:41 jnthn phew :)
19:41 FROGGS__ jnthn: about "TO LET", that doesn't work out well in germany :o)
19:41 lizmat well, they're also for rent, in a way  :-)
19:41 brrt it's really freaky to see a dutch word in the english-language channel
19:41 FROGGS__ but the first time I saw such a sign I thought: to let WHAT! WHAT?!
19:42 brrt anyway, what's fascinating is this
19:42 brrt i take a frame that numifies an object
19:42 brrt when the JIT compiler kicks in, it 'stops working' so to speak
19:42 brrt ehm... that's not right
19:42 brrt it still seems to work
19:42 brrt now i numify the object a second time
19:43 brrt this time, after JIT, the second num is always 0
19:43 brrt now instead of re-numifying the object, i copy the value of the first-numification
19:43 brrt i.e. a set
19:43 brrt still 0!
19:43 FROGGS__ jnthn: it seem to take hours using a 1024 nursery size :/
19:44 jnthn FROGGS__: Well, that is the minimum...you could probably go somewhere in the middle...
19:44 FROGGS__ k
19:44 FROGGS__ will try that now
19:44 jnthn brrt: huh...
19:45 brrt yeah
20:19 FROGGS__ jnthn: when I disable spesh it hangs in an uv loop triggered by MVM_io_syncstream_read_line -> read_to_buffer
20:21 brrt so many breakpoins
20:22 FROGGS__ :/
20:29 brrt it means 'im getting there, though
20:29 jnthn brrt++ # half of debugging is persistence...
20:30 * brrt thinks it's 90% today
20:44 FROGGS__ in the assignment here:
20:44 FROGGS__ multi postfix:<-->(Num:D \a is rw) {  # XXX
20:44 FROGGS__ my $b = a;
20:45 FROGGS__ in op assign, the object 'cont' points to has all its attrs set to zero
20:45 FROGGS__ like owner and size
20:46 FROGGS__ this is called by:
20:46 FROGGS__ method lines($limit = *) {
20:46 FROGGS__ my $l = $limit ~~ Whatever ?? Inf !! $limit;
20:46 FROGGS__ gather while $l-- > 0 {
20:46 FROGGS__ (the example code calls lines())
20:47 timotimo huh, that's curious
21:38 brrt no, i'll tell you curious
21:38 brrt somehow
21:38 brrt my num64 argument is 0
21:38 brrt even though the relevant register isn't 0
21:38 klaas-janstol joined #moarvm
21:39 klaas-janstol left #moarvm
21:39 klaas-janstol joined #moarvm
21:40 brrt what the
21:41 brrt ok, know what? i'm out, i don't get this /at all/
21:42 brrt apparantly, MVM_coerce_n_s doesn't take the second argument as xmm1, after all
21:42 jnthn o.O
21:42 brrt MVM_coerce_n_s takes the second argument as xmm0
21:42 jnthn 'cus the first argument is passed floating point?
21:43 brrt now! what is really the question, is WHY DID THIS EVER WORK IN THE FIRST ****** PLACE
21:43 brrt apparantly
21:44 timotimo oooooh
21:44 brrt the first argument is actually the threadcontext, in %rdi, where it ought to be
21:44 jnthn brrt++ # finding the bug where it wasn't expected
21:45 * brrt still can't believe that's really the cause of the bug
21:46 timotimo oh
21:46 timotimo will jitted code that handles "num" values benefit from the wider registers the cpu has to offer for floating point calculations?
21:46 timotimo rather than collapsing it to a "shorter" register between each operation?
21:47 brrt not yet timotimo
21:47 timotimo but it could do that in the future?
21:47 brrt currently, jitted code does nothing to keep intermediate values in the registers, but stores them into memory (work space) on every op
21:48 brrt it will do that in the future, once i get full register selection in dynasm
21:48 timotimo ah
21:48 brrt once that happens, though, quite a few things will still have to change in the JIT :-)
21:48 brrt nothing undoable, though
21:49 timotimo we can't undo it once we've done it? oh no!
21:49 brrt that was a dutch-ism, it seems
21:49 brrt :-)
21:49 brrt i meant nothing impossible :-)
21:49 hoelzro "I always get my sin"
21:49 brrt :-)
21:49 brrt right
21:50 brrt there must be german variants of that as well?
21:53 brrt slight annoyance: win64 does what i implemented, but posix doesn't
21:53 brrt http://msdn.microsoft.com/en-us/library/zthk2dkh.aspx see 3rd example of argument passing
21:58 brrt argh, posix abi
21:58 jnthn ugh
21:59 brrt i quote for you: "Right-to-left order on the stack makes the handling of functions that take a variable number
21:59 brrt of arguments simpler. The location of the first argument can always be computed statically, based
21:59 brrt on the type of that argument. It would be difficult to compute the address of the first argument if
21:59 brrt the arguments were pushed in left-to-right order."
22:00 brrt yes, you read that correctly; if there's too much stuff, we push arguments on the stack, but - in right-to-left order
22:00 brrt unlike microsofts abi
22:00 jnthn oh my :)
22:00 jnthn And, wtf. :)
22:02 brrt i suspect i'll have some work rewriting MVM_jit_emit_call_c
22:02 brrt :-)
22:02 brrt as far as i can tell, microsoft just has you push arguments in left-to-right order
22:02 brrt microsoft, fwiw, has just won quite a few karma points in my book
22:02 ren1us joined #moarvm
22:05 ren1us m: class A{}; my $a = A.new; my $ref = $a.WHERE; my $bogus = False; for ^10000 { if $ref ne $a.WHERE { $bogus = True; }; }; say $bogus;
22:05 camelia rakudo-moar 1372dc: OUTPUT«True␤»
22:06 ren1us apparently that's fine and the GC can do whatever it wants with regard to moving things around (so sayeth masak), but this makes the use of object keys in hashes a mess.
22:07 hoelzro (it seems like, at least on mokudo, .WHICH should not use .WHERE as the default impl)
22:07 jnthn .WHERE is completely allowed to change.
22:08 jnthn .WHICH is using .WHERE as a stop-gap.
22:08 jnthn The issue exists on JVM too, giving it can also move objects and we use the default object hash code.
22:09 jnthn The challenge is fixing this without making every single object - whether we hash it or not - bigger.
22:09 jnthn (Yes, there's some ideas for how. Just didn't get to the top of the todo list yet. But I agree it needs dealing with, and .WHICH needs to be stable.)
22:09 brrt i... think i'm going to sleep over the fix tonight
22:09 hoelzro jnthn: the JVM can move objects?  I think that the default hashCode() impl used ojbect location
22:10 hoelzro s/think/thought, s/ojbect/object/
22:10 brrt i'd be very surprised if the JVM couldn't ever move objects
22:10 brrt i've heard of more than one implementation of a moving gc
22:10 brrt (in fact, JVM's have been a hotbed of GC research for a while now)
22:11 brrt a totally correct solution doesn't seem all that easy
22:12 hoelzro no =/
22:13 jnthn hoelzro: Well, curiously, here's what the docs say: "As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects."
22:14 hoelzro ah ha
22:14 hoelzro interesting
22:14 brrt see you tomorrow!
22:15 brrt \o
22:15 brrt left #moarvm
22:15 klaas-janstol joined #moarvm
22:15 hoelzro night brrt
22:18 jnthn I *think* glancing the HotSpot code in http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/tip/src/share/vm/runtime/synchronizer.cpp that it's actually cheating and storing the hash value in some GC related slot...
22:18 hoelzro weeee
22:19 hoelzro figures
22:19 jnthn Anyway, the solution is heavily GC-intertwined
22:19 jnthn Which is what all the ones I've come up with would be too
22:21 hoelzro I figured =)
22:21 ren1us why not just make the hash the instant (now()) of the object's creation or something, effectively removing the whole memory address thing from the equation?
22:21 hoelzro ren1us: thanks for bringing this up
22:22 hoelzro ren1us: I think jnthn wants to avoid increasing a moar object's size if he can
22:22 jnthn ren1us: Yes, but how/where do we store that?
22:22 * hoelzro decommute &
22:22 jnthn Also, that's a really bad hash code, given multi-threading...
22:22 ren1us fair point.
22:23 lizmat jnthn: maybe calling .WHICH should move an object from the nursery and then give it a fixed .WHICH value stored in a slightly larger header ?
22:23 jnthn lizmat: Moving an object from the nursery means doing GC, which is gonna get costly on every WHICH. ;)
22:23 jnthn lizmat: But that is along the right lines.
22:23 jnthn lizmat: ONce an object reaches gen2 it actually doesn't move.
22:24 lizmat maybe each thread needs it's own gen1.5 ?
22:24 lizmat for those objects we call .WHICH on ?
22:24 jnthn Object refs can be shared over threads :)
22:24 lizmat true  :-(
22:24 jnthn Anyway, my idea was that if an object is in gen2 already, use the memory address
22:25 lizmat yup
22:25 lizmat also: if calling .WHICH would trigger a GC, we potentially could have a lot more GC runs
22:25 lizmat but they would be smaller ?
22:25 jnthn And if it's not, then reserve a gen2 address for it, and make an entry in a hash table of nursery address => gen2 address
22:26 jnthn And then look in that table when upgrading or sweeping objects.
22:26 jnthn GC runs carry a fixed overhead
22:26 lizmat well, hash and threads, sounds dangerous
22:26 jnthn As well as the "how many"
22:26 jnthn So protect the hash (in fact, the whole WHICH process for non-gen2 objects) with a mutex :)
22:27 lizmat ok, but that screams deadlock to me
22:27 jnthn Deadlock relies on being able to construct a circular wait.
22:27 jnthn So long as we don't do anything that could lock while holding the lock, we're good. And in this case we quite easily cna.
22:27 jnthn *can
22:27 lizmat two threads calling .WHICH on the same thing at the same time ?
22:28 jnthn One gets the lock first, sees it's nursery and needs a stable address, and so allocates it one, and makes the hash entry. Releases the lock.
22:28 lizmat well, you have more experience in that  :-)
22:28 lizmat yup, ok feels like doable  :-)
22:28 jnthn Second thread then gets the lock, sees it's nursery, sees we already made it an entyr in the hash table, grabs it, releases the lock, and done.
22:29 jnthn *entry
22:29 lizmat indeed
22:31 jnthn When I teach on deadlock I typically end up talking about the aggregate pattern as a decent structure that can avoid circular waiting arising.
22:32 jnthn Turns out you can spend days talking about the aggregate pattern too, though... :)
22:40 lizmat :-)
22:42 lizmat I guess we would need some code for the case that .WHICH gets called on something in the nursery, but it gets abandoned before a GC happens
22:42 lizmat so the reservation in gen2 would need to be undone
22:43 lizmat or always move it to gen2 (even though it should be reaped already) and leave it to the gen2 GC run ?
22:43 jnthn Well, the GC sweeper could just clear up the entry in the table and add the gen2 slot into the free list
22:44 lizmat indeed, but we shouldn't forget that  :-)
22:44 jnthn Indeed :)
23:09 dalek MoarVM: 6cce876 | jnthn++ | docs/ChangeLog:
23:09 dalek MoarVM: Update ChangeLog for 2014.07.
23:09 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6cce8767f5
23:13 dalek MoarVM: f6e89c4 | jnthn++ | README.markdown:
23:13 dalek MoarVM: Minor README feature updates.
23:13 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f6e89c4292
23:24 jnthn Will cut the release tomorrow morning, so it's done in time for the Rakudo monthly
23:24 jnthn 'night
23:25 lizmat gnight jnthn

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary