Index

Show enters and exits. Hide enters and exits.

02:23:10slavaevan: ping
02:31:16boyscoutAdded libssl-dev to Debian/Ubuntu dependencies - bc7320e - Daniel Luz
02:33:23boyscoutCI: bc7320e success. 2723 files, 10829 examples, 33841 expectations, 0 failures, 0 errors
03:00:24benschwarzlstoll!!!!!!!!!
10:55:36khaaseagainst which version of llvm do you usually compile? trunk?
10:59:06dbussinkkhaase: trunk yeah, 2.5 doesn't have all the needed stuff yet
10:59:19dbussinkkhaase: i tried trunk two days ago and then it worked fine
10:59:55khaasethanks, i'll give it a try
12:13:43cremeskhaase: evan uses revision 73074 of llvm for all of his testing so he doesn't have chase changes in trunk
12:14:11cremesi'd recommend that over the current HEAD if you want to minimize potential problems
12:14:33khaaseyou know if that plays well with clang?
12:14:48cremesno, i don't know
12:16:25khaasecremes: thanks
12:16:35cremesyou're welcome
16:48:31devinuswait
16:49:01devinusso according to the rubinius benchmarks on bench.rubini.us, rubinius is only 10-15% as fast as baseline MRI?
17:39:00evanmorning.
17:47:44mernensup evan
17:50:02evanhey
17:52:06evanbrixen: poke
17:52:14brixenyo
17:52:17mernenI was checking the LLVM crash on 64-bit
17:52:27evanmernen: ok
17:52:31mernenI'm really lost on LLVM, so I can't help much
17:52:40evanmernen: where is it crashing
17:52:47mernenbut all of my crashes were always on vm/llvm/jit.cpp, line 362
17:52:50mernenengine_ is null
17:52:55evanoh
17:52:56evanthats easy.
17:53:01evanyou're using a newer version of llvm
17:53:07mernen…oh.
17:53:30evanuse revision 73074
17:53:48evani'll take a little time today and get us working with LLVM head
17:53:55mernenok, let's see now
17:53:57evanthere were some changes to the JIT infrastructure
17:54:00evanthats why it's breaking
17:54:05evanbrixen: so, 1 things
17:54:37evan1) sliming down VariableScope even more, so that the write barrier doesn't have to be called to set locals, and it's easy to create
17:54:49brixensweeet
17:55:00evan2) investigating how to handle uncommon branches
17:55:07evan#2 is interesting
17:55:26evanthats where, normally if the guard failed, you'd execute code that just performed the send
17:55:51evanbut instead, what you do is execute code equiv to
17:56:06evanreturn rbx_uncommon(state, call_frame, ...)
17:56:30evanie, when things go wrong, you just go back and start running the method in the interpreter
17:56:54evanthe ammount of code generated is smaller
17:57:15evanand it allows LLVM to optimize more
17:57:18brixeninteresting
17:57:50evanimagine you inline an accessor, which returned just a number
17:57:57evanor rather
17:58:03evani method that returns just a number
17:58:05evandef foo; 12; end
17:58:36evanif you use the uncommon way, here's what happens for code: 1 + foo
17:59:05evanif self.class.class_id == seen_class_id
17:59:08evan val = 12
17:59:10evanelse
17:59:15evan return uncommon()
17:59:16evanend
17:59:22evanreturn 13
17:59:33evanif, instead of the return uncommon, we had
17:59:38evanval = send(:foo)
17:59:51evanLLVM couldn't constant prop the 12 and do the addition at compile time
18:00:00brixenI see
18:00:59evanso using uncommon "traps" (tahts what self calls them)
18:01:01evangives you 2 things
18:01:13evanbetter value inference (and all the optz that fall out of that)
18:01:22evanand decreased compiled method size
18:01:37brixenvery nice
18:02:06evani think it should be pretty easy to implement too
18:02:18evansince i've been making the JIT use the same datastructures as the interpreter
18:02:22evanCallFrame, VariableScope, etc.
18:03:01evanone wrinkle i haven't worked out yet is how to handle exception handlers well
18:03:11evansince the compiled code doesn't use the UnwindInfo stuctures
18:03:34evanI think i can synthesis them later on in the code, if i need them
18:03:42brixenhmm
18:03:55evanbut for now, i'm only going to emit calls to uncommon() if the code isn't inside an exception handler
18:04:01evanwe'll play with that.
18:04:09brixenyeah, sounds interesting
18:04:28brixenso, check out #load and #store in this http://gist.github.com/137701
18:04:51brixendo you think it's possible to inline #store and do only one ivar read for @table?
18:04:59brixenpulling it into a local
18:05:15brixenin generaly, you can't know @table isn't changed when you call a method
18:05:31brixenbut I know it's not
18:05:59brixenI wonder if you can get the jit to see that
18:06:42evani'd think #store could be inlined, sure
18:06:57evani read what self uses to determine which methods can be inlined
18:07:09evanand for testing i'm going to have to add explicit inlining
18:07:14evanie,
18:07:22evanFoo.instance_method(:foo).compiled_method.inline!
18:07:34evanI could just leave that in
18:07:36evanand we could use it
18:07:56brixenso, it inlines methods :foo calls or :fooL
18:07:58brixen?
18:08:06evanwhenever Foo#foo is called
18:08:08evanit's inlined.
18:08:12brixenok
18:08:22evanregardless of method size changes
18:08:29evanor the size of Foo#foo
18:08:39brixensure, that'd be useful to have to test stuff
18:44:56mernenrbx: Instructions.cpp:1627: static llvm::BinaryOperator* llvm::BinaryOperator::Create(llvm::Instruction::BinaryOps, llvm::Value*, llvm::Value*, const std::string&, llvm::Instruction*):
18:44:57mernenAssertion `S1->getType() == S2->getType() && "Cannot create binary operator with two operands of differing type!"' failed.
18:45:00mernenAborted (core dumped)
18:45:51mernentracing back to: rubinius::JITVisit::visit_goto_if_false at vm/llvm/jit_visit.hpp:1538
18:48:08evanhm
18:48:24evank
18:50:46evanah.
18:51:08evanthe ConstantInt in added and cmp need to use IntPtrTy
18:51:10evanrather than Int32Ty
19:05:09dbussinkevan: i saw a lot of places where Int32Ty was used that i thought were probably wrong
19:05:31dbussinkevan: when also investigating that failure on 64 bit, but i don't know enough about it to fix it
19:05:55evanyeah
19:06:10evanlikely just need to switch those to IntPtrTy
19:15:32evanrad, that was easy
19:15:38evanuncommon traps seem to be working
19:34:31itrekkieHi everyone- I'm reading the "getting stated" doc, and there's a reference to a dynamic interpreter, but I can't seem to find any more information, and I'm curious. Can anyone point me to more information?
19:38:03evanitrekkie: ah. the dynamic interpreter is currently gone
19:38:05evansorry :/
19:38:12evanwe may revive it at some point
19:38:18evanbut we're working mainly on the JIT atm
19:38:46itrekkieAh, that's cool. So -Xrbx.dyni does nothing?
19:38:53evannope
19:38:56evansorry
19:39:03itrekkiegotcha, thanks
19:46:29dbussinkevan: could you tell me what ConstantInt::get(Type::Int32Ty, (uint64_t)-1) means for llvm?
19:46:42dbussinki don't get the explicit type mismatch
19:48:16evanum.
19:48:29evan::get takes a Type* and a uint64_t
19:48:40evanit make look like a type mismatch
19:48:44evanbut it's not.
19:49:45dbussinkevan: i've got that first issue fixed, i now have a very clear "method 'kind_of?': given 1, expected 1 (ArgumentError)" message :P
19:50:02mernendbussink: same here
19:50:09evanhm.
19:50:20mernenI can't find a simple/easy testcase
19:50:39mernenit fails with irb and rubygems, but I can't get a single simple script that raises anything like that
19:51:19dbussinkmernen: it fails compiling readline for me with that message
19:51:37mernenyeah, that too
19:51:49mernenbasically, anything nontrivial
19:56:04evanhm. ok
20:03:08dbussinkevan: does this like a sensible change: http://pastie.org/528331 ?
20:03:49evanyes
20:06:11dbussinkhmm, github web seems to be down for me, but i could push stuff though
20:07:03mernen"@github: Rebooting the environment to reset stuck GFS locks, we'll be back up in a few minutes."
20:07:30boyscoutUse IntPtrTy for comparisons, not Int32Ty since that breaks on 64 bit - 095764b - Dirkjan Bussink
20:09:41boyscoutCI: 095764b success. 2723 files, 10829 examples, 33841 expectations, 0 failures, 0 errors
20:11:24itrekkieIs the jit built automatically, or must it be enabled at build/runtime?
20:11:35evanitrekkie: you have to enable it at build and runtime
20:11:39evando
20:11:43evanRBX_LLVM=1 rake build
20:11:45evanto enable it at build time
20:11:46evanthen
20:11:53evanbin/rbx -Xjit.enabled ....
20:11:57evanto enable it at runtime
20:15:02itrekkieIs there a way to specify where llvm is installed? or should I install a new copy in vm/external_libs? Also, is there a specific revision of llvm you're using right now?
20:15:36itrekkieSorry for all these questions, by the way, I'm having a hard time getting at the documentation
20:17:09evanitrekkie: you need llvm from svn, preferable rev 73074
20:17:22evanand it needs to be available at vm/external_libs/llvm
20:17:44evani link svn/llvm to git/rbx/vm/external_libs/llvm
20:18:30itrekkieGreat, I'll pull that revision and give it a whirl, thanks
20:18:58evanno prob
20:19:08evanrad
20:19:15evanthis uncommon trap is helping me debug the JIT nicely
20:19:25evanbecause i can now easily see all the code thats failing guards
20:48:27dgtizedIs there a way to change the threshold for number of calls before a method is jitted?
20:48:31dgtizedat runtime?
20:48:47evan-Xconfig.print
20:48:52evanthere is an option in there to do just that.
20:50:08dgtizedaweomse, thanks
20:51:11dgtizedwhoops, bin/mspec ci -T-Xjit.enabled -T-Xjit.call_til_compile=50 seems to deterministically segfault
20:52:03dbussinkdgtized: getting some errors too yeah
20:52:14dbussinknog aligned pointer being freed
20:54:10brixenwhat about eggnog aligned pointers?
20:56:38evandgtized: so, i ran some tests a while ago
20:56:47evan4000 is actually the sweet spot
20:56:51evani need to change our default
20:57:11evanok, brb.
20:57:24dgtizedthat's fine, but dropping from 75 to 50 definitely causes it to deterministically segfault
20:58:16dgtizedI'm guessing that 50 is the threshold that causes it to need to free up a bunch of methods in the cache of functions that are jitted? That's entirely a guess though
21:05:15evanyeah
21:05:17evanit's just a bug
21:05:20evanneeds to be fixed
21:07:39mernenvmm->required_args = 1, args.total() = 140733193388033
21:08:07mernen(that's 2**32+1)
21:10:54evanodd.
21:15:38devinusevan: i've been looking at the rubinius benchmarks on bench.rubini.us and was wondering if i was reading these right. rubinius is about 10-15% as fast as baseline MRI?
21:17:07evanyeah, thats what you're seeing
21:24:28dbussinkmernen: probably something that is cast back and forward a few times
21:24:36mernenevan: I see three unknown frames between BlockEnvironment::call and InlineCache::check_cache
21:24:46mernenon BE::call, args.total() = 1
21:24:55mernenon IC::check_cache(), args.total() = 2**32+1
21:25:40evanunknown frames?
21:25:48mernenyeah, gdb couldn't identify them
21:26:06dbussinkmernen: you can try building it with DEV=1
21:26:09mernenjit code, I guess?
21:26:16evanoh
21:26:16evanyeah
21:26:40evanoh
21:26:42evancrap.
21:26:46evansize_t on 64bit is 64bits
21:26:47evanyes?
21:26:54mernenright
21:26:57evanthats it.
21:27:07mernenso my build line goes to: rake build:debug RBX_LLVM=1 LLVM_DEBUG=1 DEV=1
21:27:11evanunsigned int is 32
21:27:12evanyes?
21:27:19evanwhats LLVM_DEBUG?
21:27:42mernenmakes rubinius link with vm/external_libs/llvm/Debug
21:27:43dbussinkevan: what is size_t?
21:27:51evanmernen: oh
21:27:54evandon't bother with that
21:27:57evanit's entirely unrelated.
21:28:05mernenthought it could help
21:28:09evanmernen: it won't
21:28:16evannone of the errors will be at that level.
21:28:17mernenk
21:28:48evansize_t is the common type to be used for sizes
21:29:00dbussinkevan: i mean what structure :)
21:29:05evanArguments
21:29:08evanin vm/arguments.hpp
21:29:11evanif you change that though
21:29:13mernenso that's more for LLVM-library debugging?
21:29:13evanyou need to run
21:29:18evanrake jit:generate_header
21:29:19evanmernen: yep
21:29:25mernengot it
21:29:57dbussinkevan: do you want to switch that to unsigned int or fix other stuff for size_t
21:30:40mernenabout unsigned int, I believe it should be 64
21:30:55mernenbut I'm far from a reliable source for that
21:30:55dbussinkmernen: unsigned int is 32 bits on 64 bit platforms
21:31:04dbussinklong == 64 bit
21:31:11evandbussink: switch to unsigned int
21:31:13evanor uint32_t
21:31:15evanspecificly
21:31:23evanunless you plan on having more than 4billion arguments
21:31:26evani don't.
21:31:33dbussinkhehe :)
21:31:40evan"my program state is represented entirely in on call"
21:31:47evanone call
21:31:47dbussinki'll use splat in that case then ;)
21:31:52evanheh
21:31:59evanfunny you say
21:32:03evanthat was an old bug in shotgun
21:32:25evana stack overflow because of code like this
21:32:36evanary = [1] * 8000
21:32:40evanother.push *ary
21:32:42evanBAM
21:32:45evan8000 arguments.
21:33:08evanthats why we handle splat specially now.
21:35:05dbussinkevan: that also explains the mismatch between all kinds of count stuff in the llvm jit
21:35:17dbussinkevan: size_t / unsigned int thingy that is
21:35:24evangotcha
21:36:35slavahi evan
21:36:52evanhi slava!
21:37:01slavahow do you map from machine code locations to source file locations?
21:37:24evanmy CallFrame struct has an ip field on it
21:37:29evanthats the bytecode ip
21:37:38evanand simply set it in the compiled code
21:37:42slavaso the jitted code updates a slot in the call frame as its going along?
21:37:50evanyep
21:37:55slavaouch :) ok
21:38:02evanLLVM removes the used ones
21:38:05evanit's not really much at all
21:38:15evanall the ones that are unreadable disappear
21:38:16slavahow does it know that the ip might be read or not?
21:38:20evanso only ip is set before sends, etc.
21:38:36slavaah, so between subroutine calls you don't need to keep it in sync?
21:38:44evanyep
21:38:53slavafair enough
21:39:17evanthe old assembler did pc to virtual-pc mapping
21:39:43evanthats more complicated with LLVM because I don't control the machine code emittion directly
21:39:45slavawill llvm's jit allow you to save machine code to disk too?
21:39:47evani can control it and advise it
21:39:54evanno, not right now
21:40:02evanbut thats on the roadmap for LLVM
21:40:28slavaI'm still glad I wrote my own code gen, but its a lot of work :)
21:40:32evani'd have to make my machine code portable if I did
21:40:52evanLLVM now has an interface to parts of the code gen
21:40:52slavaanother cool idea is to serialize jit profiling data somehow
21:40:56evanJITMemoryManager
21:41:02slavaso that very short running scripts can still benefit from type feedback
21:41:13evanand we're going to get to expose the relocation info eventually
21:41:16evanthen i can do whatever with it
21:41:21slavaah
21:41:29slavayeah, relocation is the tricky part about saving code to disk
21:41:34slavaI've rewritten that code a bunch of times
21:42:57evanslava: i'm working on optimizing uncommon predicted branches atm
21:43:06slavahow are you doing that?
21:43:20evanchanging it so that the code looks like
21:43:31evanif recv.class.class_id == last_class_id
21:43:38evan <inline code for callee>
21:43:38evanelse
21:43:50evan return call_interpreter(current_call_frame)
21:43:51evanend
21:44:04slavacool
21:44:06evanyou bail back to the interpreter if the assumptions don't hold
21:44:14evanthat improves alias analysis
21:44:27slavawhy not replace 'return call_interpreter' with a message send?
21:44:30evanand reduced the ammount of machine code
21:44:38evanthats what I do in some cases
21:44:44slavahow do you decide?
21:44:52evanright now, if i can use uncommon, i do
21:45:00evanuncommon doesn't handle being called inside an exception handler
21:45:04evanso i emit a send in that case
21:45:12evanthe self thesis talks about the trade offs in the 2
21:45:17evanif you do
21:45:25evanval = <inline code for callee>
21:45:26evanelse
21:45:31evanval = send(:blah)
21:45:32evanend
21:45:41evanthen you can't optimize anything for val
21:45:47evanbecause send might do anything
21:45:55evanso the rest of the method is slower
21:46:13slavayeah
21:46:13evanand since thats the uncommon case
21:46:22evanyou don't care if it's slower
21:46:29slavado you propagate type information from guards?
21:46:30evanby doing a send, you're slowing down the fast case
21:46:36evannot yet, soon
21:46:44evani'm adding uncommon support as legwork for generic method inlining
21:47:13slavain factor, if you do something like dup array? [ "Oops" throw ] unless then the rest of the word is compiled assuming the value is an array
21:47:26slavabut its a static optimization on source
21:47:37evanyep
21:47:47evani'm going to likely add explicit inlining for testing too
21:47:53evanso we'll be able to lean on that.
21:48:15slavayou can annotate kernel methods with explicit inlining annotations
21:48:41slavaalso you can compile certain selector sends to have a static fast case, if there's no runtime type info yet
21:48:42evanyep
21:48:48slavaeg, if something is calling + there's a good chance its on fixnums
21:48:52evanright
21:48:54evani do that now
21:49:02evanbecause the bytecode does
21:49:06evanand actually, i've got extra info there
21:49:16evanbecause meta_send_op_plus now has an IC too
21:49:25evanso i can actually see "was it actually a fixnum most of the time?"
21:49:28slavayeah
21:49:37evanand if it was, say, a float
21:49:46evanand can emit inline code for float addition
21:50:08slavaif you add 'is float' goards and the uncommon case traps, then the rest of the method can ssume the values are floats, and unbox them
21:50:26slavallvm probably won't do this automatically
21:50:31dbussinkevan: cool, got passed building readline extension with llvm enabled :)
21:50:35evandbussink: yay!
21:50:39slavabut you can add unboxed float opcodes to your bytecode format perhaps
21:50:39evanslava: no, it won't
21:50:45evanslava: but I can add some LLVM passes
21:50:56evanto help it along
21:55:32slavaevan: do you think any of the jit code you've written could be contributed back to llvm-jit, or another separate project? is everything rubinius-specific/
21:56:04evanthere are generic parts
21:56:21evanone thing I do want to write is a generic compiletime/runtime type check system
21:56:30slavathat sounds very broad
21:56:56evanwell, mainly i want to have a simple API and some passes
21:57:04evanfor doing type checks
21:57:15evanthat would end up being simple integer comparisons
21:57:29slavaah
21:57:31evanand using some LLVM passes to allow for guard elimination
21:57:53evani'm not going to get into type theory, thats up to the user
21:57:59evanbut they'd have to boil their type down to an int.
21:58:03evanwhich should be easy.
21:58:46evanthe unladen swallow guys are starting to do some type analysis stuff
21:58:58evani'm going to follow their lead and see if i can't do similar things
21:59:02evanthough, from everything i've been reading
21:59:14evani'm better of ignoring type analysis
21:59:20evanand leaning 100% on type feedback
21:59:24boyscoutUse uint32_t for Arguments total - 10c90c8 - Dirkjan Bussink
21:59:30dbussinkmernen: i've been able to complete a spec run now, some minor failures though
21:59:54slavaevan: with a langauge like ruby that's your best bet
21:59:55evandbussink: did you do "rake jit:generate_header" ?
22:00:16mernendbussink: I'm running spec right now
22:00:20dbussinkevan: no, but i think it was the correct size already since it was probably made in a 32 bit system with a 32 bit size_t
22:00:23mernenlooking good so far
22:00:41dbussinkevan: it worked without doing it, i don't llvm-g++ on that machine atm either
22:00:44evandbussink: ah
22:00:47evanyes
22:00:47dbussinkso i just tried and it worked
22:00:50evanactually thats was the issue
22:00:58evanLLVM has total as
22:01:06evanIntegerType::get(32)
22:01:15evanso you just fixed it so that assumption holds true :D
22:01:45dbussinkevan: yeah, but i thought that was ok in llvm, since i could imagine having enough with 32 bit sized counts :)
22:01:53evanyeah
22:01:54evanthats fine
22:01:57evanit did the right thing
22:02:01evanand so did you!
22:03:40boyscoutCI: 10c90c8 success. 2723 files, 10829 examples, 33841 expectations, 0 failures, 0 errors
22:04:00evanslava: btw, the other reason setting ip in call_frame is no biggy is that call_frame is stack allocated
22:04:13evanso i'm never really worried about it going out to main memory
22:04:24dbussinkevan: bin/mspec ci -B full.mspec -t ruby segfaults on 64 bit machine, so we can claim rubinius works better there :p
22:04:35evanhah
22:04:37evanOUCH
22:04:54dbussinkdefault debian lenny ruby
22:07:19dbussinkmernen: how does it look?
22:08:03mernenindeed a couple new failures
22:13:20dbussinkmernen: hmm, i see some spec failures but they don't fail if i run the spec file directly through mspec :S
22:16:03mernenagh, I cleared the failures terminal
22:20:59mernenI can still reproduce the ipaddr failures here
22:25:11mernenit won't fail with call_til_compile=0 or 500
22:26:06dbussinkmernen: did you add the -Xenable.jit too?
22:26:59mernenno, is that really necessary?
22:27:04mernendoesn't seem to change the results, anyway
22:27:32dbussinkmernen: yeah, because otherwise the jit isn't enable
22:27:50dbussinkso call_til_compile doesn't do anything without the jit enabled
22:27:55dbussinkbut that also crashes it with 32 bit
22:28:00mernenyou sure? since the beginning I've been running without jit.enabled
22:28:11mernenand it seemed to work fine
22:28:37dbussinkit works fine, but it doesn't jit :)
22:28:52mernenI mean, all those jit crashes I've looked at
22:29:03mernenat most, I was playing with jit.call_til_compile
22:29:06dbussinkwell, those are some llvm parts that are used
22:29:10dbussinkhmm, strange
22:29:20dbussinksince dgtized reported something else i guess then
22:29:23mernenthe jit always seemed to be there
22:29:51dbussinkwell, i know that isn't enabled unless you provide that option
22:30:02dbussinkyou can see it with ./bin/rbx -Xconfig.print
22:31:21mernenevan: is it necessary to pass in -Xjit.enabled for the jit to work?
22:31:36mernenI've been running it all day without that switch, even playing with jit.call_til_compile
22:31:56mernenand judging by all the crashes, the jit did seem to be there
22:32:22evanmernen: you must be setting -Xjit.enabled
22:32:30evanjit.call_til_compile does nothing otherwise
22:32:52boyscoutAdd uncommon branch support - 10d2362 - Evan Phoenix
22:33:10mernenweird
22:34:03evanit had to be something else
22:34:05mernenhow did I manage to get the crashes, the failures, the jit frames and all then?
22:34:56evani don't know
22:34:58evanhow were you running it?
22:35:41mernenno special flags, just bin/rbx and possibly some usual arguments like script paths
22:35:58evanyou weren't running in the JIT
22:36:09mernenplus mspec ci -T-Xjit.call_til_compile does affect the number of failures I get
22:36:09evani can't believe you were.
22:36:16mernenseriously
22:36:34evanum.
22:36:35evando
22:36:36mernenbin/mspec ci -T-Xjit.call_til_compile=0 library/ipaddr => no failures
22:36:40evanbin/rbx -Xconfig.print
22:36:41mernenbin/mspec ci -T-Xjit.call_til_compile=50 library/ipaddr => many failures
22:36:53evandoes it say the jit is on?
22:36:55mernenconfig.print and everything I can think of just tells me jit is off
22:37:02evanit's not on then.
22:37:08evanwhy that causes failures, I don't know
22:37:11evando
22:37:13evan-Xjit.show
22:37:19evanand you can actually see if it's on
22:37:26mernenyes, lots of jit info
22:37:28boyscoutCI: 10d2362 success. 2723 files, 10829 examples, 33841 expectations, 0 failures, 0 errors
22:37:31evanWHAT?!
22:37:33evanno
22:37:35evancan't be.
22:37:36mernenyes!
22:37:40evanbullshit.
22:37:43mernenthe jit has become sentient!
22:37:48evanno really
22:37:50evanthat can't be.
22:38:29dbussinkevan: freaky stuff, i'm seeing it on 64 bit too :)
22:38:35evanoh come on
22:38:38mernenI'd try it on the mac, but I don't have LLVM compiled here
22:38:39evanstop pulling my leg.
22:38:46mernenmeans it'd take a while
22:38:52dbussinkevan: http://gist.github.com/137833
22:39:08dbussinkdoesn't show anything in my mac
22:39:11evanwhat
22:39:11evanthe
22:39:12evanfuck
22:39:17dbussinkjust gives me the terminal there
22:39:27evanhow the fuck can that be!?!
22:39:55evanhm.
22:39:57mernenyou've neglected the 64-bit builds for too long
22:39:59dbussinkmaybe the config variable suffers from some sort of 32 / 64 bit issue that checks some random bit?
22:40:04mernennow they are working on their own
22:40:10evandbussink: if that were true
22:40:14evanthen -Xconfig.print
22:40:16evanwould say true
22:40:21evanbecause that tests that flag.
22:40:23mernenRubinius::JIT also says false
22:40:31evanhuh?
22:41:06evanwho added Rubinius::JIT...
22:41:07evananyawy.
22:41:13mernenwell, it always seems to return false anyway
22:41:23mernenguess I don't know what it's for exactly
22:41:26evanwhat about with -Xjit.enabled
22:41:33evanwhat does it say
22:41:44mernenjit.enabled config.print does say true
22:41:51evanthe code on vmmethod.cpp:501 and 502
22:41:56evanmust be wrong for 64bit
22:42:06evanif the JIT isn't enabled
22:42:09evancall_count should be -1
22:42:13evanand that branch never entered
22:42:17mernenI'll check that
22:42:34evancall_count is a native_int
22:42:39evanwhich is 64bit
22:43:25dbussinkevan: and jit_call_til_compile is an int...
22:43:46dbussinklooks like another classic 32 / 64 bit comparison gone wacky :)
22:44:06evanwhy the fuck doesn't gcc warn you!?
22:44:10evanfuck you gcc.
22:44:20evanbut anyway
22:44:24evanthat shouldn't even be entered!
22:44:34evanunless "0" is 32bits!?
22:45:12dbussinkthe comment says // A negative call_count means we've disabled usage based JIT
22:45:29dbussinkso it's probably assigned some negative value that is wrapped around at some point
22:46:00evanwrapped around from what though?
22:46:02evanif it's negative
22:46:05evanit should never be touched
22:47:46dbussinkdunno, but something is fishy there at least
22:47:58dbussinkbut i should really get some sleep, early morning tomorrow
22:48:07mernenevan: call_count = 1
22:48:09mernenerm
22:48:09mernen0
22:48:21dbussinknite ppl
22:48:37mernencya dbussink
22:49:25evanmernen: where is that?
22:50:29mernenjust set a breakpoint on line 501 before running, and the very first time it's reached vmm->call_count is 0
22:50:49evanbut but but
22:50:51evanthat can't be.
22:51:22evanmernen: walk through what happens on line 123 of vmmethod.cpp
22:51:31mernenk
22:51:37evanwithout -Xjit.enabled
22:51:41evanthat should always be false
22:51:44evanso that call_count is set to -1
22:54:28mernenbad news, the condition is true
22:54:37evanwait wait.
22:54:48evanhow the hell can that be.
22:54:52mernenoh
22:54:55mernenwait, there's something wrong here
22:54:59evanwell
22:55:01evanthats an object
22:55:07evanwith a operation bool()
22:55:14evaner, operator bool()
22:55:17evanso print it
22:55:20mernengdb actually threw me into line 131
22:55:33evanwtf.
22:55:40mernenanyway
22:55:42evando this with DEV=1 compiled.
22:55:56mernenI just made a clean build, DEV=1
22:56:04evancome on gcc.
22:56:08evanwtf are you doing.
22:56:21evanok
22:56:26evan on line 124
22:56:32evanchange jit_enabled
22:56:37evanto jit_enabled.value
22:56:44evansee what happens
22:56:50mernenevan: http://gist.github.com/137841
22:57:06mernenI'm still confused by the line number anyway
22:57:19evanno
22:57:21evanyou can't do that in gdb
22:57:44evangdb won't run the operator method
22:57:51mernenoh
22:57:54evanso casting to bool doesn't do what you think it does.
22:57:56mernenanyway, value = false
22:58:02evansure
22:58:05evanbut actually change the condition
22:58:07mernenso I guess it is indeed running line 131
22:58:09evanand see if it still does
22:58:14evanie, remove calling the operator bool()
22:58:30evanwtf
22:58:36evanis USAGE_JIT not defined?
22:59:02evanDOH
22:59:05evanslaps himself.
22:59:24evanremove the #ifdef USE_USAGE_JIT
22:59:30evanin all places in that file.
23:00:03evanactually, i'll do
23:00:06evanthere are a few places.
23:00:45evanok, one sec.
23:00:52evanthis was a legacy configuration fuckup.
23:00:54evanon my part.
23:00:59mernenin this specific file I only found two places, that test we were before and this conditional
23:01:27evanyeah
23:01:27evanone sec
23:01:31evani'm about to push a removal
23:02:24boyscoutRemove USE_USAGE_JIT flag - a2debe2 - Evan Phoenix
23:02:25evanok, try that..
23:05:23mernenbtw, is DEV=1 enough to ensure a debug build? I'm using build:debug right now
23:05:44boyscoutCI: a2debe2 success. 2723 files, 10829 examples, 33841 expectations, 0 failures, 0 errors
23:05:44evanyes
23:05:47evanthey're the same
23:06:19mernenbin/rbx no longer has jit
23:06:35evanhuh?
23:06:46mernenI mean, it's no longer magically on
23:06:50mernenbut -Xjit.enabled crashes very quickly
23:06:53mernenterminate called after throwing an instance of 'rubinius::Assertion'
23:06:58evan:/
23:07:33mernenvm/exception.cpp:30, "Only supported on x86"
23:07:56evani need the full backtrace
23:07:57evando
23:07:58evancatch throw
23:08:01evanthen get the backtrace
23:08:07evanthats a bunk exceptoin being thrown
23:08:52evanok
23:08:53evani see it.
23:09:34evanDER.
23:09:40evanneed
23:09:52evanactually
23:09:52evanone sec.
23:11:02evandid you set MM_DEBUG?
23:11:18evanoh oh
23:11:19evanno
23:11:19evannm.
23:11:49evanincoming!
23:11:54boyscoutRemove crufty platform check - 0c8637a - Evan Phoenix
23:12:03evantry that.
23:12:10ddubless cruft!
23:13:15mernenwill try it in a sec
23:15:04boyscoutCI: 0c8637a success. 2723 files, 10829 examples, 33841 expectations, 0 failures, 0 errors
23:15:08mernen"Unknown VM exception detected."
23:15:11mernenhttp://gist.github.com/137849
23:16:00evanok...
23:16:01evanum.
23:16:09evancan you debug that?
23:16:14evanor do you need to me try?
23:17:23mernenI can try
23:24:33mernen…or maybe I can't, seems beyond my knowledge
23:26:02mernenanyway, it won't crash for very small or large values of jit.call_til_compile
23:26:54mernenbbiaw
23:27:16evanwhat about with the default value?
23:27:34evanusing uncommon branches seems to save about 59 bytes of machine code per callsite
23:27:38evannot bad.
23:28:24mernenthat's roughly <30 for small values, >2800 for large values
23:29:11mernenso my deductive powers say something's going wrong during the transition
23:29:15mernenanyway, gtg
23:30:02evanok
23:30:12evani'm not going to look at it until i have a real 64bit machine to test on