Index

Show enters and exits. Hide enters and exits.

00:10:26ddubgets a big grin on his face
00:10:31ddubsomeone forked urb
00:21:25evanhaha
00:21:31evandid they add anything?
00:29:32mernenback
00:43:01ddubevan: yes, a configure script!
00:43:10ddubnow I have cross-platform build
00:43:24ddubunfortunately, they only added configure and not the corresponding configure.ac
00:43:37ddubso its now by far the largest thing in the repo
00:43:45evanhah
00:43:46evancourse
00:43:59evangenerate configure files are larger than 50% of the projects that use them.
00:44:02evangenerated
00:44:33ddubI submitted a patch for ragel because 95% of my compiled java code size was the tables it was generating
00:44:44evanunsurprising.
00:44:47ddubthere is a limit on how large a pre-defined array or a method can be
00:45:33ddubso rather than putting it in a single array, they allocated one statically and called table[3251] = 4; table[3252]=5;
00:45:41ddubin methods like build_1, build_2, build_3
00:45:48dduband a static build that called all those methods in sequence.
00:46:17ddubthe generated stack code for all that was immense. As was the debug information
00:46:57ddubI instead defined multiple private static final arrays and had a static method to build the working jump table from them.
00:47:18ddublo and behold, my jar shrunk to 25% of its previous size
00:47:46ddubwhats next on the rubinius optimization path?
00:48:42ddubprimitive inlining, phase 1?
00:51:04evanprimitive and FFI inlining are soon, yes.
00:51:11evanas well as generic method inlining
00:59:49ddubI wish there was some way we could work together
00:59:54ddubbut urb doesn't really need any of that
01:00:12evanhah
01:00:14evantrue
01:00:20evanno methods to inline or specialize
01:00:48ddubI may need to write a paper on my method of evaluating code in constant time
01:01:20ddubits all about how you define the word 'evaluating'
01:02:23evanyour program, given a program that modifies no state, computes in constant time
01:02:57evan(results may vary given programs that modify state)
03:01:19ddubevan: programs that modify state are so... dirty
06:29:38tmorniniHowdy all. I get hanging specs when I run sometimes, no CPU usage, unable to cntl-c. Have you seen this?
06:31:24brixentmornini: I'm assuming you are running with the jit on?
06:31:47tmorniniYes, correct. Trying to narrow down with -V now.
06:32:07brixenyeah, it's a known issue that most commonly afflicts linux
06:32:31brixenyou can gdb vm/vm <process id> when it hangs
06:32:37tmorniniOK, seeing it regularly here on OS X, happens in different specs.
06:32:41brixenbt should tell you where it is hung
06:32:47brixendo bt 10
06:32:58tmorniniWhat do I issue that into?
06:32:59brixenthen look for a frame that has call_frame as an arg
06:33:20brixenso, you've got the specs running in one terminal
06:33:24brixenit appears to hang
06:33:35tmorniniYes
06:33:39brixenin another terminal, ps ux | grep rbx
06:33:46brixenget the pid
06:33:56brixenin the rbx dir, run gdb vm/vm pid
06:33:57tmorniniOK
06:34:05brixenthat will attach to the running process
06:34:14brixenonce your are in gdb, bt 10
06:34:38brixenlook for a call that has call_frame
06:34:52brixentype p call_frame->print_backtrace(state)
06:35:11brixenlook at your original terminal and you should have a ruby backtrace
06:36:48tmorninihttp://gist.github.com/138014
06:37:44brixensorry
06:37:50brixenfr 3
06:37:52brixenthen run that
06:38:00brixenyou have to switch to that frame
06:38:19brixenjust pass the symbol state
06:38:47tmorniniOK, waitpid
06:40:35tmorninifascinating! wait_spec just blew up...
06:41:03tmorninihttp://gist.github.com/138017
06:41:10tmorniniI've seen this before.
06:41:23tmorniniBut all this is happening more regularly now than before.
06:41:42evantmornini: type
06:41:43evanframe 3
06:41:45tmorniniIn any case, you already know about this, so I'll be quiet now. :-)
06:41:48evanp call_frame->print_backtrace(state)
06:41:52evanand gist the output
06:41:56evanwe need to see the real thing.
06:42:08tmorniniHey Evan.
06:42:12evanthe backtrace will show up in the other terminal.
06:42:31tmorniniI've seen two different behaviors, hang and this: http://gist.github.com/138017
06:43:00tmorniniIf it will hang again, I will gist that up as well.
06:43:02evanwhat about that file?
06:43:07evanjust the file doesn't tell me much
06:43:13evancan you get me a backtrace?
06:43:24tmorniniYeah, but the process is terminated at that point.
06:43:29evanwhy
06:43:31evanit shouldn't be
06:43:32tmorniniI did not terminate it...boom!
06:43:33evanyou're in it via gdb.
06:43:42tmorniniNo, not in that one.
06:43:46tmorniniDifferent behavior.
06:43:55tmorniniSometimes it just terminates all by itself, just like that gist.
06:44:07evani'm confused.
06:44:10evanbut if you get a hang
06:44:12tmorniniOK, I'm hanging in fork_spec now. Will gist it up.
06:44:16evanplease generate a C and a ruby backtrace
06:44:22tmorniniDoing right now.
06:47:23tmorninihttp://gist.github.com/138021
06:48:36tmorniniJust edited gist to include C backtrace
06:49:08ddubis incredibly tired
06:49:30evanhm
06:49:31evanok
06:49:38evanmutex locking problems it looks like
06:49:48evanhopefully i can repro tomorrow and see it
06:50:34tmorniniHow long has this been happening? The terminate thing popped up a few times over the last couple of weeks, but the hanging is quite recent.
06:50:35ddubewww
06:50:42ddubwhat is posix behavior if you fork while holding a lock?
06:50:46evantmornini: i dunno how long
06:50:51evanit's not happening to me or brixen
06:50:54evanor anyone else
06:50:59evanwe saw it a few times on linux
06:51:04evanbut i haven't yet debugged that.
06:51:07tmorniniHanging seems to have started with a new laptop.
06:51:20evan"the terminate thing"
06:51:21tmorniniTerminate has been here for a while.
06:51:22evanwhats that?
06:51:36tmorninihttp://gist.github.com/138017
06:51:58evanthat doesn't say anything
06:52:02evani don't know what i'm looking at
06:52:14evanoh, it's wide.
06:52:20tmorniniThere you go.
06:52:24evanlooks like the same thing.
06:52:31evanbut I dunno
06:52:34evanhaven't see it here.
06:52:40tmorniniPerhaps, but sometimes it hangs, othertimes it outputs that and terminates.
06:52:50tmorninii.e. they appear different.
06:52:51evanterminates means crashes
06:52:54evantypically.
06:53:03evanif you open up Console.app
06:53:07tmorniniOK, so if it's the same bug, sometimes it hangs, othertimes it crashes.
06:53:11evani'll bet there are a whole bunch of crash logs for it
07:00:38tmorniniWhere are crash logs stored?
07:18:33evanum
07:18:37evanlook in console.app
07:18:40evanthey should be in there somewhere
16:48:20manveruevan: shouldn't rubyspec say that Object#extend takes multiple modules?
16:48:31manveruerr Kernel#extend
17:17:01evanmanveru: yes
17:22:01manveruk...
17:22:20manverusomeone should run facets against the rubyspec :P
17:31:18brixenmanveru: yeah that's a good idea
17:32:01brixenmanveru: at my rubyspec talk, someone suggested loading ActiveSupport and running the specs
17:32:21brixensee if Rails changes exiting Ruby APIs or only extends them
18:10:37evanmy my, fiddling with how local variables are looked up causes all kinds of fun stuff to fail
18:11:39brixenheh
18:11:47brixennow where did that local go
18:12:26evani'm making it so the set/push_local opcodes do the sensible thing
18:12:42evanwhich is, always manipulate the current scope
18:12:50evanbefore, they always manipulated the top_scope
18:13:00evanwhich, in a block, is the top most creater scope
18:13:03evanwhich was just silly.
18:14:12brixenahh yeah
18:17:45evanthe way i'm reorganizing them
18:18:01evanlocals in the current scope can be written always without running the write barrier
18:19:26brixensweet
18:21:45evanGR.
18:21:50evanthe library specs are crashing.
18:52:37dbussinkevan: nasty crashes?
18:53:05evannot sure yet
18:58:47dbussinkevan: btw, saw you guys found the 64 bit jit issue, funny one :p
18:59:44evanyeah
18:59:51evansilly macros
19:07:55dgtizedso any idea why the bin/mspec ci jit benchmark is consistantly failing to give a result?
19:08:23evannope
19:09:18dgtizedcould boyscout run twice, once without jit, and then once with?
19:09:27evanit does.
19:10:17dgtizedhuh, alright, I guess I had not caught that
19:10:55dgtizedthat gets posted to integrity as well or no?
19:11:03evanno
19:11:08evanintegrity is just CI.
19:12:31brixendgtized: you can run the benches yourself
19:12:38brixensee benchmark/utils/cron_daily
19:12:51brixensee if you can track down why it doesn't finish
19:14:10dgtizedbrixen: is there a way to only run the ci portion of the benchmark, since that is the portion that fails?
19:15:00evandgtized: read the scripts
19:15:04evanyou'll see it in there.
19:15:09brixenbenchmark/utils/README
19:28:32dgtizedit just says that the status was a Timeout
19:28:56dgtizedit doesn't generate any other logs other then the benchmark/results yaml file?
19:38:22dgtizedcan someone try running: rbx -Xjit.enabled mspec/bin/mspec-ci spec/frozen/core
19:38:43dgtizedthat appears to hang on some spec
19:39:06dgtizedI'm trying to attach a gdb instance to it, but there are several processes, and it's not clear which one has hung
19:39:42evandgtized: it's a linux problem
19:39:51evanplease try and debug it
19:39:55evanit's on my list of things to get to
19:40:32mernendgtized: is jit running fine for you?
19:41:37dgtizedmernen: if I do a bin/mspec ci -T-Xjit.enabled it works fine, but specifically running rbx to use mspec/bin/mspec-ci is not
19:41:44mernenyesterday I was getting into a recursive loop while initializing the vm
19:42:03mernennot even rbx -e '' would run without overflowing the stack
19:42:29dgtizedevan: I have two processes in a wait_pid, one in a fork, one in a mutex_lock
19:43:03dgtizedand two defunct processes
19:43:53dgtizedmernen: rbx -e '' works fine for me, as does rbx -Xjit.enabled -e ''
19:57:05mernendgtized: weird, I just made a clean build and I'm still having problems
20:23:33dbussinkmernen: i'm seeing failures on 64 bit with jit.enabled
20:24:18mernenI don't just see failures, I'm completely unable to use rbx with jit.enabled
20:24:44dbussinkmernen: yeah, crashes for me too
20:24:57dbussinkmernen: but 64 bit hasn't really been tested recently
20:25:22mernenreverting the uncommon branch commit it seems to work (at least doesn't crash, haven't tested more)
20:25:26mernenI'm checking that now
20:26:42evanmernen: oh
20:26:46evanthats it.
20:26:49evander.
20:27:03evanthe uncommon branch code is computing the sp value wrong on 64bit
20:27:12mernenevan: I'm looking at the changes to jit_operations
20:27:19mernenptrtoint, subtract_pointers
20:27:23evanyeah
20:27:28evansubtract_pointers is wrong on 64bit
20:27:33evanit needs to divide by 3
20:27:40evanat the very least
20:27:54evanit also needs to use IntPtrTy rather than Int32Ty
20:28:01evanwhen it converts the pointers to ints
20:28:04evanso they don't get truncated.
20:29:23mernenI still don't understand the division by 3 though
20:30:04evanbecause the pointers are 8 bytes wide
20:31:12evanit's doing pointer math
20:31:32mernenI expected just to divide by 8
20:31:45evaner.
20:31:50evanyes.
20:31:51evansorry.
20:31:57evanshift by 3
20:32:01evanis what i was thinking
20:32:06mernenoh, okay
20:32:06evansame diff
20:32:10mernenyeah, makes sense now
20:32:42dbussinkevan: testing with sizeof(uintptr_t) / 8 now
20:32:58evank.
20:37:46mernenthis is what I've got: http://gist.github.com/138362
20:38:54evanthats wrong
20:38:58evanthe change in JITVisit is wrong
20:39:03evanthat should stay Int32Ty
20:40:11mernenI should cast the result of subtract_pointers to int32 then?
20:41:19evansure
20:41:27evanwell actually
20:41:32evanyou can change that
20:41:43evanbut you need to change continue_uncommon
20:41:50evanand VMMethod::uncommon_interpreter
20:48:06mernenI think I see it
20:50:22dbussinkevan: looks like it's even necessary to prevent all kinds of type mismatches in llvm
20:50:32evancould be
21:01:08dbussinkevan: what's the easiest way to see where a Assertion `S1->getType() == S2->getType() && "Cannot create binary operator with two operands of differing type!" comes from?
21:01:11dbussinkgdb?
21:09:40mernenevan: updated it http://gist.github.com/138362
21:10:54dbussinkmernen_: does it run with jit with these changes?
21:11:09mernenit runs basic tests, but segfaults easily
21:11:12mernenI'm investigating that
21:14:32slavahowdy evan
21:47:00dbussinkmernen: any progress?
21:48:17mernenwell, turns out it crashes even without jit
21:48:56mernenso that might be good news, depending on how you see it
21:49:01dbussinkmernen: hm, that doesn't happen for me atm
21:49:10mernentry: bin/rbx -rmatrix -e ''
21:49:19mernenor mspec ci
21:49:23mernenboth crash very quickly here
21:49:41dbussinkhmm, works for me here
21:49:45dbussinkon 64 bit
21:50:38mernenok, lemme try a clean build again then
21:54:27mernenyeah, it works now
21:55:17mernenthough mspec ci library/ipaddr still crashes, jit or not
21:55:58dbussinkmernen: strange, it doesn't crash on it for me
22:59:51mernendbussink: well, if it works for you, I'm gonna push it
23:00:02mernenmaybe I'll check my crashes later
23:02:08boyscoutMake uncommon branch code word size-independent - d91ad2a - Daniel Luz
23:06:48boyscoutCI: d91ad2a success. 2723 files, 10829 examples, 33841 expectations, 0 failures, 0 errors
23:44:39dgtizedhow come this is considered particularly newsworthy? http://www.infoq.com/news/2009/06/macruby-drops-gil-threading
23:48:33slavawhy not?
23:49:06yakischlobashouldn't it be?
23:50:22yakischlobathe 'primary' ruby implementations don't have parallel thread execution, so it is worth noting that that one now does
23:52:52dgtizedwell for one it neglects to comment on what extent rubinius has partial removal of the GIL
23:53:11yakischlobadoes that make the topic un-newsworthy?
23:54:08dgtizedno, but it makes it less balanced and more like hype without substance
23:54:27yakischlobai think hype without substance would be like
23:54:39yakischlobaa title of "macruby removes gil!" and then article body stating "macruby PLANS to remove the gil"
23:55:29yakischlobathe article seems to state that something was actually done
23:56:22yakischlobamaybe you could email the author and let them know that you think rubinius should be mentioned
23:56:43yakischlobathat doesn't mean there should not be an article telling us about what macruby is doing