Show enters and exits. Hide enters and exits.
| 00:49:44 | ddub | waves |
| 03:32:00 | brixen | mri never ceases to amaze me |
| 03:32:09 | brixen | rb_hash_size is *static* |
| 03:32:32 | brixen | so of course people write completely unportable INT2FIX(RHASH(obj)->tbl->num_entries) in their code |
| 03:32:35 | brixen | wtf |
| 04:57:27 | ddub | brixen, how many rb_hash_sizes do you need? |
| 04:57:30 | ddub | :) |
| 08:02:36 | boyscout | Use an InlineCache for block sends in the JIT - d5a7829 - Evan Phoenix |
| 08:05:52 | boyscout | CI: d5a7829 success. 2709 files, 10767 examples, 33779 expectations, 1 failure, 0 errors |
| 08:47:02 | boyscout | Put ICs on the meta_* send ops - 9c0134c - Evan Phoenix |
| 08:56:43 | boyscout | CI: 9c0134c success. 2709 files, 10767 examples, 33781 expectations, 0 failures, 0 errors |
| 17:14:31 | evan | morning. |
| 17:22:22 | dgtized | morning |
| 17:54:15 | brixen | evan: this is what I get building on elle http://gist.github.com/134074 |
| 17:54:26 | brixen | dunno how boyscout CI is building |
| 17:54:37 | brixen | builds fine on os x after a rake clean too |
| 17:54:43 | evan | UM. |
| 17:54:45 | evan | crap. |
| 17:55:53 | evan | run |
| 17:56:00 | evan | ruby vm/codegen/instruction_macros.rb |
| 17:58:07 | brixen | same error |
| 17:58:38 | evan | huh. |
| 17:58:41 | evan | remove that file in gen |
| 17:58:49 | brixen | k |
| 17:58:50 | evan | gen/inst_list.hpp |
| 17:59:41 | brixen | removed; rake -q; regens it, same error |
| 18:02:39 | evan | wtf. |
| 18:02:45 | evan | check your compiler/iseq.rb |
| 18:03:00 | evan | make sure that those instructions have an arg now |
| 18:03:37 | brixen | :args => [:literal] |
| 18:03:47 | evan | weird. |
| 18:03:48 | evan | ... |
| 18:03:52 | evan | umm. |
| 18:04:07 | evan | h oh |
| 18:04:08 | evan | oh oh |
| 18:04:08 | evan | der. |
| 18:04:17 | evan | i wonder why this didn't blow up on OS X |
| 18:04:20 | evan | ok, give me a sec. |
| 18:04:22 | brixen | k |
| 18:10:06 | brixen | ahh boyscout does not build with jit enabled, that explains that |
| 18:10:41 | brixen | of course my ubuntu vbox built fine for the same reason |
| 18:11:12 | brixen | probably works on os x because of gcc 4.0 |
| 18:17:24 | brixen | when the top google link for 'ubuntu libc man pages' is ubuntu forums, maybe you should think about a reasonable package name |
| 18:17:37 | brixen | or how about install it with build_essential |
| 18:59:26 | brixen | evan: I'm tracking this (semi random) abort running syck and I'm wondering if there is a place to insert a guard on LookupData fields |
| 18:59:30 | brixen | see http://gist.github.com/134095 |
| 18:59:45 | brixen | by the time Object::send gets called, the data is garbage |
| 19:00:04 | brixen | in MRI TYPE() would just do a bit flag test, but we send #kind_of? |
| 19:00:51 | brixen | since this is a sensitive call path, not sure if as<Module> somewhere from LookupData constructor up that bt would be appropriate |
| 19:01:10 | brixen | I think it would be good not to segfault/abort on this sort of thing |
| 19:09:11 | evan | hm. |
| 19:12:49 | evan | lets see |
| 19:12:50 | evan | well |
| 19:13:45 | evan | so |
| 19:13:54 | evan | i'm guessing that dest is getting missed by the GC |
| 19:14:25 | evan | given how it blows up on method lookup |
| 19:14:29 | brixen | probably |
| 19:14:30 | brixen | yeah |
| 19:14:44 | brixen | it only happens running full specs and compiling |
| 19:14:58 | evan | sure, thats probably enough GC churn to make it happen |
| 19:15:00 | brixen | which is a problem itself |
| 19:15:19 | evan | so, how does syck advise the GC that there is a GC pointer in ->bonus ? |
| 19:15:26 | brixen | but I'm concerned about that resulting in a segfault if a capi ext does a bogus rb_funcall |
| 19:15:40 | evan | ah! |
| 19:15:41 | brixen | um.. |
| 19:16:09 | evan | well, it's easy enough to validate the handle |
| 19:16:42 | evan | actually, in this case |
| 19:16:52 | evan | if it IS being collected behind ->bonus's back |
| 19:17:00 | evan | then the handle pointer has probably been free'd too |
| 19:17:06 | evan | hm. |
| 19:18:05 | brixen | there is syck_mark_emitter(emitter) that calls rb_gc_mark on bonus and it uses Data_Wrap_Struct to pass around the emitter_xtra structs |
| 19:18:34 | brixen | it's some generally horrific code but runs all the specs except 2 |
| 19:18:43 | brixen | not that there's many specs, but still |
| 19:19:09 | evan | hm. |
| 19:23:37 | evan | brixen: we could set a flag in the memory of the GC handle when it's free'd |
| 19:23:56 | evan | and if env->get_object() tries to use a handle that has the free'd flag set, we print out and error and abort or something |
| 19:24:01 | evan | thats not foolproof |
| 19:24:05 | evan | but it's better than nothing |
| 19:24:13 | brixen | yeah, that would be good |
| 19:24:20 | brixen | at least as controlled abort |
| 19:24:25 | brixen | s/as/a/ |
| 19:24:27 | evan | if we to get 'fancy' |
| 19:24:32 | evan | the handle could hold a checksum |
| 19:24:42 | evan | and we validate the checksum on get_object |
| 19:25:22 | brixen | well, the flag would be a good start |
| 19:26:51 | evan | hm, so what would the controlled abort be... |
| 19:28:44 | brixen | well, we could just raise an exception |
| 19:30:55 | evan | yeah |
| 19:33:03 | boyscout | Style cleanup - 15b06aa - Evan Phoenix |
| 19:33:03 | boyscout | Fix operand changes - 73824ab - Evan Phoenix |
| 19:36:44 | boyscout | CI: 73824ab success. 2709 files, 10767 examples, 33780 expectations, 0 failures, 1 error |
| 19:36:59 | evan | 1 error? |
| 19:37:00 | evan | wtf. |
| 19:42:39 | boyscout | Add trivial checksuming to capi::Handle to aid in debugging - a09b9b1 - Evan Phoenix |
| 19:44:33 | evan | brixen: try running with that |
| 19:45:45 | brixen | k |
| 19:45:52 | evan | I didn't raise an exception |
| 19:45:56 | evan | but at least it should do detection |
| 19:46:10 | evan | it's using a fixed checksum of 0xffff |
| 19:46:15 | brixen | the other fields in that extra struct are valid, so still looking at the port field |
| 19:46:20 | brixen | k |
| 19:46:20 | evan | and validates it's 0xffff on access |
| 19:46:24 | brixen | le'me pull |
| 19:46:25 | evan | so if it's invalidate memory |
| 19:46:36 | evan | it's likely not going to be 0xffff |
| 19:46:43 | evan | but some other random collection of bits |
| 19:46:51 | brixen | k |
| 19:47:13 | boyscout | CI: a09b9b1 success. 2709 files, 10767 examples, 33781 expectations, 0 failures, 0 errors |
| 20:14:58 | slava | hi evan |
| 20:16:49 | evan | hey slava |
| 20:16:50 | evan | hows things? |
| 20:16:55 | slava | good |
| 20:17:00 | evan | slava: oh, on your PICs |
| 20:17:06 | evan | when you detect a new class |
| 20:17:13 | evan | you always enlarge the PIC and add it, yes? |
| 20:17:32 | slava | there's a maximum size |
| 20:17:42 | evan | how many is your max size? |
| 20:17:54 | slava | 3 by default |
| 20:18:12 | evan | then you revert it to a slow lookup version? |
| 20:18:28 | slava | yeah |
| 20:18:42 | evan | k |
| 20:19:07 | evan | i'm adding the ability to track classes seen at each call site |
| 20:19:12 | evan | up to 3 |
| 20:19:20 | evan | then tracking how many times it overflows |
| 20:19:28 | evan | info to be used by the inliner |
| 20:19:55 | slava | cool |
| 20:25:03 | slava | what kind of speedup are you seeing with JIT -vs- interpretation now? |
| 20:25:18 | evan | depends on the code |
| 20:25:27 | evan | on some code, a lot |
| 20:25:39 | evan | atm though, the common cases aren't getting much of a speed up |
| 20:25:44 | evan | i'm investigating that now |
| 20:26:05 | brixen | evan: heh argh! I got the abort in a regular build, but couldn't look at the checksum in gdb because it was optimized out, ran in debug and it didn't abort |
| 20:27:22 | brixen | I'll have it print the checksum when it aborts |
| 20:27:59 | brixen | evan: btw, did you see the bench graphs for rdoc with no jit? |
| 20:28:11 | brixen | it got slower, but the jit times are faster |
| 20:28:27 | evan | hehe |
| 20:28:29 | evan | ok |
| 20:29:42 | brixen | I haven't investigated, just stands out on the top graph |
| 20:30:01 | evan | hm. |
| 20:30:01 | evan | ok |
| 20:30:36 | evan | geez |
| 20:30:38 | evan | it got a lot slower |
| 20:30:46 | evan | good to see that we solved the threading issue though |
| 20:30:51 | evan | mspec has stabalized |
| 20:31:22 | evan | it jumped by a good 80s |
| 20:31:23 | evan | thats... |
| 20:31:24 | evan | odd. |
| 20:35:40 | brixen | yeah, the specs are much better |
| 20:36:40 | brixen | the raw yaml files are in my home/devel/rubinius/benchmark/results |
| 20:36:47 | brixen | the file names are explanatory |
| 20:37:12 | brixen | not seeing any weirdness in the rdoc times, just that they are a lot longer |
| 20:37:30 | evan | odd. |
| 20:37:31 | evan | ok |
| 20:37:37 | evan | i'll go back and do a little bisecting. |
| 20:42:06 | brixen | we create (and free) a ton of capi handles during a full spec run |
| 20:42:14 | brixen | so generally, it is working well |
| 20:42:26 | evan | good. |
| 20:42:27 | brixen | can't get the abort running a debug build :/ |
| 20:43:17 | evan | i hate those bugs. |
| 20:43:48 | brixen | me too |
| 20:44:04 | brixen | really, I have no desire to poke around in yaml/syck |
| 20:44:10 | brixen | I was so happy when it was working |
| 20:44:11 | brixen | :) |
| 20:44:20 | evan | heh |
| 22:31:03 | brixen | sigh |
| 22:31:14 | evan | sup? |
| 22:31:16 | brixen | evan: I ran that damn thing in debug and non-debug a dozen times |
| 22:31:21 | brixen | no abort |
| 22:31:25 | evan | :( |
| 22:31:27 | brixen | ran it one more time, abort |
| 22:31:28 | brixen | :) |
| 22:31:33 | evan | hah |
| 22:31:34 | brixen | the checksum is 0x0 |
| 22:31:40 | brixen | so, it's apparently freed |
| 22:31:44 | evan | yep |
| 22:32:06 | evan | the handles use a refcount scheme |
| 22:32:10 | brixen | yeah |
| 22:32:18 | evan | so perhaps the refcount isn't being maintained properly |
| 22:32:19 | brixen | but it's so random, how do I track this? |
| 22:32:25 | evan | it's rough. |
| 22:32:31 | evan | GC bugs are the worst. |
| 22:32:44 | evan | i usually nuke all .rbc files |
| 22:32:49 | evan | and try to get it to happen that way |
| 22:32:57 | evan | then I always run it again with them nuked |
| 22:32:58 | brixen | it appears to always be on bonus->port, which is the sink for the yaml outputter |
| 22:33:05 | evan | to try and stabalize the patterns |
| 22:33:40 | brixen | I've only been able to trigger it on a full spec run compiling |
| 22:33:47 | brixen | ie after rake clean |
| 22:34:02 | evan | right |
| 22:34:08 | evan | can you make it happen reliabily that way? |
| 22:34:15 | brixen | no |
| 22:34:56 | evan | UG> |
| 22:35:02 | evan | ummm |
| 22:35:38 | evan | these are the bugs where you stab in the dark |
| 22:35:48 | evan | you have to check where that port handle is usesd |
| 22:35:54 | evan | and try and figure out where the bug might be |
| 22:35:55 | brixen | well, the one consistent thing appears to be bonus->port |
| 22:35:56 | brixen | yeah |
| 22:36:00 | evan | and add some defensive coding |
| 22:36:03 | evan | and see if it oges away |
| 22:36:09 | brixen | k |
| 22:36:18 | yakischloba | do you guys use libev or libevent? |
| 22:36:23 | brixen | I've checked that it's initialized correctly |
| 22:36:45 | evan | yakischloba: libev, but since we switch to stackfull, it's not used much |
| 22:37:16 | yakischloba | cool. |
| 22:37:29 | yakischloba | is there a reason you chose it over libevent/what was your opinion of it? |
| 22:37:41 | evan | we used to use libevent |
| 22:37:55 | evan | one of our contributers wanted to use libev |
| 22:37:58 | evan | and converted us over. |
| 22:38:07 | yakischloba | hmm |
| 22:38:14 | evan | i'm not clear on the merits of one over the other |
| 22:38:23 | evan | i'm not a big fan of the libev codebase |
| 22:38:24 | yakischloba | its supposedly newer/better/faster but i havent really found anyone using it |
| 22:39:13 | evan | the libev is pretty oppressive |
| 22:39:34 | yakischloba | how so |
| 22:40:29 | evan | the style sucks, imho |
| 22:40:50 | evan | it's just kind of a mess |
| 22:40:58 | evan | i've tried to fix bugs or figure out why it did certain things |
| 22:41:06 | evan | it's hardly trivial to even follow what it's trying to do |
| 22:41:26 | yakischloba | hmm k |
| 22:45:07 | dbussink | didn't you work on that tarcieri? |
| 22:48:48 | yakischloba | *doh* yeah i suppose i should have asked him lol |
| 22:52:54 | slava | yakischloba: there's nothing magical about non-blocking I/O APIs. both libevent and libev have serious flaws and I suspect the developers are inexperieced |
| 22:53:03 | slava | its best to roll your own at this stage |
| 22:53:39 | yakischloba | lol really? |
| 22:57:07 | yakischloba | are they that bad? |
| 22:58:13 | slava | last time I looked at the code I wasn't very impressed, they don't even support windows |
| 23:00:57 | yakischloba | okay. |
| 23:03:34 | larrytheliquid | evan: made those double-check for the less common case performance changes to dataflow, and added it to rubyforge in case you want to play with it |
| 23:07:14 | evan | eh? |
| 23:10:00 | larrytheliquid | evan: concurrency lib stuff we talked about at the ey hack day |
| 23:11:20 | evan | ah! yes sorry |
| 23:11:21 | evan | awesome |
| 23:39:20 | yakischloba | recommendations on testing framework for C? |
| 23:39:54 | evan | we use cxxtest for C++ |
| 23:39:56 | evan | it's fine |
| 23:40:00 | evan | nothing to get excited about |