thsig has quit [Read error: Connection reset by peer]
thsig_ has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/cgFUTw
<JRubyGithub>
jruby/master 8dab723 Chris Seaton: [Truffle] During warmup some benchmarks become metamorphic until splitting, so need to explicitly transfer.
JRubyGithub has left #jruby [#jruby]
calavera has joined #jruby
<headius>
chrisseaton: hey, interested in your thoughts on a known problem: call sites rooting temporary objects
<headius>
e.g. a singleton object method cached at a call site will keep that object alive forever... unlike non-singleton object methods, which will only keep that class alive
<headius>
could be avoided by having call sites be a weak reference, but that obviously means traversing a weak reference every time (along with the many other reasons weak references can get messy)
<chrisseaton>
won't that just reference the singleton class
<headius>
we have opted to just not fix it, and have it be a known side effect of method caching that singleton objects may stick
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 3 new commits to master: http://git.io/dwUUCg
<JRubyGithub>
jruby/master be557da Thomas E. Enebo: Make frame requirement calculation a small method in ACP
<JRubyGithub>
jruby/master 9d24f55 Thomas E. Enebo: Register end block to toplevel scope so JIT can know it exists
<JRubyGithub>
jruby/master 0961f2d Thomas E. Enebo: For methods and other scopes do not mandatorily not allow ACP to run on them...
JRubyGithub has left #jruby [#jruby]
<headius>
the singleton class holds a reference back to the object
<chrisseaton>
ah yeah
<chrisseaton>
is it a memory leak problem, or are people expecting objects to disappear from weak references, ObjectSpace and finalisers and things?
<headius>
we tried to make that connection weak once, but we ended up with a bunch of methods in flight that no longer had an "attached" object
<headius>
the latter... it's not really an unbounded leak, since it will only retain as many objects as there are live call sites
<headius>
that's another reason we haven't prioritized researching a fix
<chrisseaton>
ah well if it's the latter, tell people that GC guarantees you nothing ever and to get used to it - not even MRI guarantees that :)
<headius>
sounds about like our official policy on the matter
<enebo>
heh
<headius>
it might be worth looking at having the class reference stored in the call site be weak *only* when that class reference is to a singleton class
<headius>
that would mean singleton methods require weakref traversal at call sites, but singletons usually trigger heavy invalidation anyway and don't cache well
<enebo>
And of course we need to use that policy for IR tmporary variables pinning objects unless we introduce a pass to nil out temp vars after they are no longer referenced
iamjarvo has joined #jruby
<headius>
enebo: yeah, that will be an interesting one...old JIT and old interpreter likely had the same issues though
<headius>
local variable in Java that holds a reference to something it shouldn't...same effect
<headius>
those are all over the AST interpreter
<enebo>
headius: well AST interp probably did not have it since everything was a function call with a return from a function
<chrisseaton>
one option is deopt-alot - Graal does this - deoptimize and clear call sites every now and again
<enebo>
headius: we did have living nodes hold some values so I concede a little bit of it
<chrisseaton>
good for the case where your setup code uses on call site cache, but never again
<chrisseaton>
Truffle doesn't use it yet though
<headius>
chrisseaton: yeah, I have been thinking about how to productively do periodic flushing
<headius>
one of the indy smalltalk impls does a periodic flush
<chrisseaton>
had a thread on a timer, deoptimsie everything, clear all caches, start going again - not great in the middle of a request though
<headius>
could also track all call sites currently holding references to weakrefs and only periodically flush those
<headius>
it gets messy every way though
<headius>
er, holding references to singleton objects
elia has quit [Quit: (IRC Client: textualapp.com)]
elia has joined #jruby
<chrisseaton>
we could have a chaos monkey - randomly deoptimising methods and resetting call sites - but not all at once, just one at a time here and there
<chrisseaton>
would be very probabilistic (so guarantees nothing, just like the GC)
<chrisseaton>
at least we're not in Jython's position with ref count semantics
ivan\ has joined #jruby
iamjarvo has quit [Read error: Connection reset by peer]
iamjarvo has joined #jruby
<headius>
chrisseaton: eesh, don't remind me
<headius>
pretty sure they just punt on it though
<headius>
is the truffle python doing ref counting?
<chrisseaton>
the conclusion was we wanted to support --help in RUBYOPT, so instead of changing the behaviour that's why I included the strict option
<enebo>
asarih: sorry I thought this was recent
<enebo>
chrisseaton: so we can certainly support it. It was more whether we want to go through the trouble
<enebo>
chrisseaton: I don’t quite read that we want it supported from this issue though. More we did not want to take the time to fix it
<chrisseaton>
I'm happy to do that if it's ok
<enebo>
chrisseaton: yeah that would be great since you would kill two birds with one stone
<enebo>
of our remaining 61 failing tags that is about 20 of them
colinsurprenant has joined #jruby
ahadding1 has joined #jruby
<chrisseaton>
ok - it's on my todo list
avsej_ has joined #jruby
avsej has quit [Ping timeout: 255 seconds]
avsej_ is now known as avsej
mkristian has joined #jruby
<headius>
enebo: I modified InterpretedIRMethod to only JIT IRMethod instances, and with that change every method successfully JITs running rspec with threshold=0
<headius>
I'm not sure if it's valuable to JIT non-method bodies (other than blocks) but we can revisit that later if we like
<enebo>
headius: ah yeah I did not check to see where that was ahppeneing
<headius>
ahh you saw the cast errors?
<enebo>
headius: yeah I do not remember the exact reason for doubling down on using interpretedIRMethod for non methods but it was probably just easier to implement
<headius>
yeah... InterpretedIRMethod is really just a vessel
<enebo>
headius: I did not but I knew last week when I saw no debug info
<headius>
it may be the only DynamicMethod for all IR soon
<enebo>
headius: I corrected that problem (debugging) by moving the debug above JIT check
<headius>
I guess I see it clear the same flag in computeScopeFlags
<headius>
hmm
<enebo>
ZSuperInstr does
<enebo>
in compuireScopeFlags
<enebo>
chrisseaton: I asked a question about your tags above too
lance|afk is now known as lanceball
<chrisseaton>
enebo: I'd already removed them as we were running specs with the strict option, but thanks for the reminder
<enebo>
chrisseaton: ah ok
<byteit101>
JRuby is clearly doing something strange with JavaCV, my ruby code calling openCV works always, but java .class works never, and java .jar works only if ruby has called openCV.
<headius>
chrisseaton: maybe I should have reviewed this, but Rubinius has to do almost all the same tricks to make Array and String internals accessible from C
calavera has joined #jruby
<headius>
e.g. copying data back and forth, duplicating content in native heap and managed heap
<chrisseaton>
oh didn't know they actually did copying
<chrisseaton>
post a comment :)
<headius>
they have to...they don't have pinning and lifecycles of object handles will cross GC boundaries
<enebo>
byteit101: If I had to guess Mat is trying to load something else not in your classpath
<enebo>
byteit101: try ‘java_import “theclass”’ and see if you get a better error
<enebo>
byteit101: I think java_import for some reason has a more detailed error
<byteit101>
yea, except it works *after* jruby has called it
<enebo>
byteit101: nice to see you btw :)
<byteit101>
indeed, I also made some fixes to jrubyfx recently
<byteit101>
supports j8 now
<enebo>
byteit101: great
<enebo>
chrisseaton: Did I see an earlier version of this blog post?
<enebo>
chrisseaton: It feels like I read this already
<enebo>
chrisseaton: Out of all the stuff you guys have done the thing which has blown my mind the most is the C interpreter :)
<chrisseaton>
enebo: we sent out the Modularity paper draft a month or more ago
<enebo>
chrisseaton: It is one of the more unintuitive solutions to the non-inlining issue (at least to me)
<headius>
chrisseaton: FYI, tweets that start with @ only go to that person and people who follow you both
<chrisseaton>
oh bollocks
<headius>
that's why people will insert a space or . before a leading handle
<enebo>
I mean it make sense but it I never ever thought of it as a solution
<byteit101>
enebo: java_import has no effect
<brixen>
Rubinius pins Strings
<brixen>
we could pin Arrays as well, but don't at the moment
<headius>
brixen: so as long as the handle is alive, that string cannot be moved, yes?
<headius>
by the GC, that is
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius>
brixen: thanks for clarifying...what's the lifecycle of handles + pinning in that case? Can a String stay pinned even after C ext call returns to Ruby?
<headius>
chrisseaton: FWIW, JVM accessors for array elements (which I believe we use in our C ext stuff) *can* pin, but I'm not sure if they do on most current JVMs
<chrisseaton>
if you've allocated on the heap, you've already lost for a lot of the benchmarks
<enebo>
We also lost because we go through JNI :)
<headius>
well, I make no claims that JNI could ever be efficient for C ext
<headius>
and that's probably the biggest reason we ditched C ext support
<byteit101>
enebo: interesting. java_import 'org.bytedeco.javacpp.opencv_core$Mat' results in same error as java, but simply putting the reference `org.bytedeco.javacpp.opencv_core::Mat` (w/o backticks) works and fixes it just like java
subbu|lunch is now known as subbu
<enebo>
byteit101: I guess technically $ is an internal encoding thing
<byteit101>
?
ludyte has left #jruby [#jruby]
<byteit101>
opencv_core is a class with "public static class Mat" inside it
<enebo>
byteit101: internally the class is named that but in Java and Ruby we cannot refer to an inner class with a $
<enebo>
at a lang-level
<byteit101>
yes, well, it can't find it with . or :: inside a string
<byteit101>
NameError: cannot load Java class org.bytedeco.javacpp.opencv_core.Mat
<byteit101>
vs
<byteit101>
NameError: cannot link Java class org.bytedeco.javacpp.opencv_core$Mat, probable missing dependency: org.bytedeco.javacpp.opencv_core$Mat.allocate()V
<byteit101>
which is the same error as java get
<subbu>
headius, enebo i am lazy to read the scrollback now .. so, will let you two figure it out .. have to also focus on some parsoid things.
<headius>
subbu: yeah I'm on it, just FYI
<enebo>
byteit101: I think using :: makes sense and . does not but the string form probably does not split on :: which is a bug
<byteit101>
NameError: cannot load Java class org.bytedeco.javacpp.opencv_core::Mat
<byteit101>
yea
<byteit101>
want me to report that as an issue?
<enebo>
byteit101: yes please
<enebo>
byteit101: I also believe this code is in core/src/main/ruby/* so you may even be able to fix if that tickles your fancy
pietr0 has joined #jruby
<byteit101>
cool, though I think my jruby source is > 1 year out of date so I may need to pull :D
<byteit101>
any idea on why the const ref can fix the java and jruby errors loading the jni class?
benlovell has joined #jruby
<enebo>
byteit101: I predict you fix :: on the string form and it will do the same thing
<enebo>
byteit101: It is probably classforname on the opencv_core::Mat as a single name
<byteit101>
I don't, thats a seperate bug
<byteit101>
because simply calling my java class (Java::Test.new) causes the error
<byteit101>
and adding a reference to Mat in jruby fixes it
<headius>
bleh, I need to step debug ACP to find this
<headius>
I have no idea why it's adding frame and scope
amdprophet has quit [Ping timeout: 272 seconds]
locks_ has joined #jruby
<subbu>
headius, is it happening in interp mode as well?
mjc_ has joined #jruby
Fofrik has joined #jruby
amdprophet has joined #jruby
lopex has joined #jruby
imperator has joined #jruby
<byteit101>
enebo: it boils down to a JavaUtilities.get_proxy_class('org.bytedeco.javacpp.opencv_core::Mat') call which gets into the guts of jruby fast. Should I just replace :: with $ in the java_import (impl ruby) or the get_proxy_class (impl java) or lower?
<headius>
subbu: checking
<byteit101>
the actual conversion is in javasupport, which looks to be called by everything
<headius>
subbu: yes
<subbu>
so should be simpler to debug in interpreter land.
<enebo>
byteit101: You could do it on Ruby side we do not document get_proxy_class but if it receives a Ruby string it basically just does a Class.forName
yfeldblum has quit [Ping timeout: 245 seconds]
skade has quit [Quit: Computer has gone to sleep.]
<byteit101>
ok, yea i figured that out after several layers of abstraction
<byteit101>
:)
<enebo>
byteit101: It would be a starting point anyways. I see lots of consumers of that internally so perhaps we go sleuthing after you make a PR
<enebo>
byteit101: My only other thought is that ‘org::bytedeco::javacpp::opencv_core… is valid
<enebo>
byteit101: I don’t think we want to try every permutation
<byteit101>
sub(/::/, "$") ?
<byteit101>
that way only $ can be replaced ?
<enebo>
byteit101: but do we do n tries?
<byteit101>
tries?
<enebo>
org$bytedeco$javacpp .. or org.bytecodeco$javacpp …
<byteit101>
oh, no
<byteit101>
not in the code I saw
<enebo>
byteit101: I guess I am realizing :: and . create some ambiguity
<byteit101>
oh
<byteit101>
oh!
<enebo>
but you can have innner classes in inner classes
<enebo>
I guess it could try n times from the back
<enebo>
forward references are ‘.’ initially and rear references are ‘$’
<enebo>
Start with all ‘.’ then all but last ‘$’ then all but last two as ‘$'
<byteit101>
yea, though I always though java_import was java-style syntax
<enebo>
byteit101: well we could do that too
<enebo>
byteit101: If it is a string we just punt and ‘::’ won’t work
<byteit101>
hence I didn't realize what you were talking about with gsub("::",".")
<enebo>
byteit101: If it is not possible then I guess we could then just throw an error
<enebo>
byteit101: with a helpful message
<enebo>
byteit101: I was thinking about it from the angle of it working anyways
<headius>
enebo, subbu: Ok...it looks like super instructions all get a %block argument even if there isn't one
<enebo>
byteit101: but with multiple tries this seems icky
<headius>
that's causing it to full deopt
<byteit101>
I did like the idea of making it slightly more consistent with :: => $ only
<byteit101>
but I agree with your ick
<headius>
maybe that check on CallBase should just go away?
<headius>
we have other checks for closures in lexical scope
* subbu
is busy with deploys. back later.
<enebo>
headius: I don’t think we can remove it unless you know the method the super is in cannot have an implicit block
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<enebo>
headius: A super can pass the block through…we could possibly not use block(0:0) and use an actual temp
<headius>
hmm
<headius>
but only zsuper does it without explicitly passing something, right?
<headius>
or have I forgotten super's crazy semantics?
<headius>
actually no, that still shouldn't matter for this because it's still not a block in this lexical scope
<enebo>
headius: I was referring to the implicit nature of blocks overall. I guess in that sense we do pass it around internally
<headius>
it's from some other scope
<enebo>
headius: yeah so perhaps I am wrong. Maybe it can be eliminated. I am confused on %block’s role in analysis. I know for inlining it is important since we can have mutliple blocks in play in that scenario
<enebo>
each one needs to be renamed and kept track of
<headius>
this check basically just says if there's ANY block passed to a call, deopt
<headius>
even if it's not a literal block
<headius>
and supers all get a block param regardless of containing method
<headius>
so....
<enebo>
yeah so implicit block we just pass down to super anyways I think
<enebo>
headius: in debug output if you see it have (0:1) or syntax like that is refers to depth/offset which means binding
<enebo>
So you probably see %block(0:0) = recv_closure as third instr of that method
<headius>
yes, 0:0
<headius>
if it's a literal closure, after linearization I should see WrappedIRClosure as the operand, right?
<headius>
I need to change this logic to only deopt for literal blocks, not blocks passed in other ways like &block
<enebo>
wrappedirclosure is for a lexical closure
<headius>
right
<headius>
that's the deopt case
<enebo>
what is?
robbyoconnor has quit [Ping timeout: 265 seconds]
<enebo>
we are talking about receiving a closure to the method
<enebo>
so we we a live Block instance and store it into a variable of some kind
<enebo>
oh shit…hahaha…Something was confusing me with -S ast —ir and I just realized what it is
<enebo>
I am seeing every method print out as broken
<enebo>
It is storing variables away but has no binding push
<headius>
eh?
<enebo>
but in prepareForInterpretation we add ACP in an if statement
<headius>
hmmm
<enebo>
So ast program does not know that and prints it out without that pass
zorak8 has joined #jruby
<enebo>
not really related to what you are talking about but I cannot see what it is actually doing because AST no longer works correctly
<enebo>
I guess I can run these and generate the output with debug on
<headius>
I'm trying an instanceof check on the closure operand... if it's WrappedIRClosure I trigger deopt
<headius>
but I'm worried about WrappedIRClosure getting loaded into an intermediate temp var
<enebo>
for which instr?
<headius>
in CallBase
<enebo>
on the callsite site not the definition side
<nirvdrum>
subbu: Today is rough. I'll give master a look tomorrow.
<headius>
weird...ALMOST everything works, but I get two failures in rubyspec: Java::JavaLang::ClassCastException: org.jruby.RubyClass cannot be cast to org.jruby.runtime.Block
<headius>
enebo: yes, call site side...it's the calls (supers) that are causing deopt unnecessarily
<headius>
any call that passes a block arg through would deopt with the current code, though
<enebo>
headius: I am not sure exactly I am following what you are trying to do but I will point this case &a will just contain an IRubyObject whereas a foo {} would contain a WrappedIRClosure
johnmuhl_ has joined #jruby
Scorchin has quit [Ping timeout: 244 seconds]
<headius>
hmm
<enebo>
(IRubyObject == variable accessed)
<headius>
enebo: that cause would deopt for the proc {} call
<headius>
&b block passing should never cause deopt
<enebo>
well here let me show you something and perhaps we can change it
<headius>
ok
subbu has joined #jruby
Scorchin has joined #jruby
chrisseaton has joined #jruby
<enebo>
headius: The def for the foo above generates this:
<enebo>
b(0:0) = recv_closure
<enebo>
%block(0:1) = copy(b(0:0))
<headius>
ok
<headius>
none of that should cause deopt
<headius>
but call(... %block) does
<headius>
and should not
<enebo>
headius: What I am wondering is whether load store pass is convering block to a temp
iamjarvo has joined #jruby
<headius>
hmm
<enebo>
%t_b_2 = recv_closure
<enebo>
%t_%block_3 = copy(%t_b_2)
<enebo>
yeah it does rename the block
<headius>
enebo: def foo; bar(&b); end deopts
<headius>
that's what I'm trying to fix, because it's affecting all supers since they implicitly pass block through
<enebo>
yeah I see
<headius>
but my patch causes two failures...weird ones, like it doesn't know where to load the block from anymore
<headius>
I can show you what I have
guilleiguaran___ has quit [Ping timeout: 272 seconds]
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<headius>
enebo: there's no need to deopt anything there, I'm 99% sure
<enebo>
This is not all passes applied but it does not eliminate the scope
pietr0 has joined #jruby
<enebo>
subbu: headius realized if it is a variable for closure and not a lexical one it should not deopt
<enebo>
subbu: but I am guessing either load/stores make it deopt after he tries to make callbase smarter about closure argument
<enebo>
subbu: Maybe related question we must be able to run ACP multiple times? Or does interp and JIT run it exactly once at the end?
<enebo>
headius: 99%…I like those odds
<subbu>
acp cannot run multiple time.
<enebo>
…yet
<enebo>
:)
<subbu>
well, once you add a push/pop binding, you dont need to add it again.
<subbu>
unless you want to remove all of those and rerun the pass .. not sure why you would want to.
<enebo>
subbu: unless you apply a pass which removes the reason you added those instrs in the first place
<headius>
I'm getting this behavior running threshold=0
<subbu>
yup.
<enebo>
subbu: I guess I don’t either since I was going to say inlining but that would be a new method
<headius>
I feel like I'm not communicating something well
<subbu>
makes sense.
<enebo>
headius: Did my description sound right?
<headius>
parsing
<headius>
enebo: after my fix, it does not deopt...but a yield somewhere in a spec blows up trying to find its block
<headius>
in the interpreter
<headius>
hmm
<enebo>
heh
<headius>
shoot, I bet that's it
<enebo>
headius: ok that is different
<headius>
it's removing the scope but not doing local var load/store
<enebo>
yield is using it implicitly
<enebo>
in that case it cannot deopt
<headius>
getting IR for the broken case
<enebo>
since a lexical closure is trying to access it
<enebo>
more importantly how can push_binding not exist if the scope has load/stores in it?
<enebo>
Seems a little more primal to me
<headius>
ok, both failures are the same thing
cprice_ has joined #jruby
cprice_ is now known as cprice404
<subbu>
headius, enebo you probably already know this .. but when for scope foo in that example above, here is what I see: For scope:INSTANCE_METHOD foo[-e:0], escaped binding? true; require frame? true; require binding? true
<subbu>
headius, i cannot build with the diff patch.
<enebo>
subbu: I was thinking about debugging IR and it would be nice if we stored enums for reason why a flag was toggled
<enebo>
subbu: possible even a full object
johnsonch is now known as johnsonch_afk
johnsonch_afk is now known as johnsonch
<headius>
subbu: run with indy and that won't happen
<headius>
but this affects interpreter anyway
<headius>
I removed a method JVM6 needed
<subbu>
ah, ok.
<enebo>
subbu: we could print out pass and instr/oper or some other info so we know why some flag was marked
<headius>
testing that this rebuilds and then I will update patch
johnsonch is now known as johnsonch_afk
<subbu>
headius, ok .. i can copy that code outside the mspec harness and run it directly .. the failure is reproduced.
yopp has joined #jruby
skade has joined #jruby
|jemc| has joined #jruby
<chrisseaton>
yopp: cast aside your preconceptions about C code, and think of it as a language like any other - an if statement in C is very much like one in Ruby
<chrisseaton>
yopp: and we run it very much like we do Ruby
benlovell has joined #jruby
<yopp>
so basically instead of AOT compilation, you will, uh, interprete C?
<headius>
block(0:0)
<byteit101>
enebo: so do you think I should add "::" -> "$" and make java_import with strings slightly more rubyish, or leave it $ only as a "I am importing this java reference into ruby, and that is how the jvm specifies it"
<headius>
it should be at least two deep, right?
<chrisseaton>
yopp: yeah, and if we are interpreting both C and Ruby, we can interpret them together, and the division between Ruby and C becomes irrelevant
<headius>
I bet receive_closure logic is not getting fixed when we optimize leaf scope away
<headius>
oh, but if scope goes away, it *should* be at depth zero
<enebo>
byteit101: I think it should be documented as saying this is Java calling format but we can probably look for ‘::’ in code and generate a better error message since I don’t think that is allowable in classname
<yopp>
because having backtrace to C code is sounds a-w-e-s-o-m-e
<byteit101>
ok
<chrisseaton>
yopp: yeah - we've had that idea - both C extension and Ruby code in one unified backtrace
<chrisseaton>
yopp: maybe with all the local variables from both languages shown as well
<yopp>
chrisseaton, but what about platform specific stuff? If we have shitty driver, with platform-specific intstructions, then what?
<headius>
yopp: plus performance and allocation profi ling, step debugging through C code...
<enebo>
headius: yeah either depth is wrong it should be (1:0) or something removed a recv_closure from the block
<yopp>
headius, yeayeayea!
<headius>
pretty exciting stuff
<chrisseaton>
yopp: it's unlikely to work for all code - but it can also call compiled native code if you have it - so you can call into your database driver or your Qt library, or your Win32 API or whatever
<enebo>
I am confused about this error case I thought the optimization only worked if not a lexical closure
<|jemc|>
chrisseaton: so you would parse c calls to code you don't have source for as FFI calls?
<headius>
optimize dynamic scope pass removes dynscope from closure if it's a leaf
<chrisseaton>
|jemc|: yeah, and the FFI is very fast as the JIT knows about C calls
<headius>
and then fixes up scope load/store to have depth - 1
<enebo>
headius: yeah fixes the depth
<chrisseaton>
FFI is a great use case - no wrapper or configuration layer - write a line of inline C to include the header and make the call
purplefox has joined #jruby
<|jemc|>
chrisseaton: attractive indeed
benlovell has quit [Ping timeout: 265 seconds]
<headius>
hmmm
<chrisseaton>
|jemc| yopp will you be at RubyConf?
<headius>
enebo: I'll try to get the IR for the surrounding body
<headius>
there's so much dumped out
<yopp>
nope, I don't have US visa :|
<|jemc|>
chrisseaton: nope, unfortunately I can't get away
Aethenelle has joined #jruby
<|jemc|>
but I'll be sure to follow your progress :)
<chrisseaton>
ah right - we'll I'll try to get around to some more EU conferences and show it off
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/QK3R7Q
<Aethenelle>
chrisseaton: waiting for a plane right now... saw your blog post about C ext on truffle/jruby... have you tried running cFFI under that implementation?
<headius>
enebo: I think that's it...surrounding scope does not have a recv_closure here
<enebo>
haha
<headius>
so never allocates slot for the block and it's getting used for something else
<enebo>
laughing at subbu not like that extra output :)
<chrisseaton>
Aethenelle: no I haven't - we didn't evaluate the FFI either - maybe we should do
<yopp>
chrisseaton, ping me when you will ge to EU :) I'd like to meet with you
<chrisseaton>
Aethenelle: are there any major gems using FFI?
calavera has joined #jruby
<headius>
0mq bindings
<headius>
that's one I know is in active use
<Aethenelle>
chrisseaton: I don't know off hand... most that I knew of switched to native Java for jruby support... I know I use it at work whenever I have to deal with a native lib but that's because I'm usually writing throwaway code.
<headius>
Aethenelle: hate to ask about this, but what's the status of prepend PR now?
<headius>
we have about two weeks before preview
<|jemc|>
headius; chrisseaton: 0mq bindings are actually my use case :)
<headius>
nice
<chrisseaton>
I'll take a look at them
<chrisseaton>
headius: will there be a freeze at some point?
<|jemc|>
although I may end up moving to the czmq bindings instead
<enebo>
subbu: You realize this works if you replace Class.new with HashDB < Hash?
<enebo>
subbu: I just made up a class name
<Aethenelle>
headius: what's wrong w/ asking about it? It needs some more work... I'll push the current work (i had to start w/ a fresh branch)... I'm dealing w/ a inf look in unresolved/instanceSuper right now but it shouldn't be too bad to fix from here...
<headius>
chrisseaton: probably talk about that after rubyconf, but e.g. truffle stuff that won't be done anyway doesn't have to freeze
<headius>
Aethenelle: ok...I have a better understanding of the super instructions now that JIT is "done" so once you update I'll try to help
pietr0 has quit [Quit: pietr0]
mister_solo has quit [Ping timeout: 265 seconds]
<Aethenelle>
headius: I think one of the recent pushes also broke some of my already working impl (probably a bad rebase) but I'll circle back to that once I get the right one working...
<subbu>
alright, heading home. back online in 15 again.
<headius>
I don't think it should need to get block from binding in this case, though
<headius>
we can fix that later though
<headius>
unresolved doesn't affect most common supers
<headius>
Aethenelle: ok
<headius>
Aethenelle: so this will fail, yes?
<Aethenelle>
yes, test_prepend fails w/ a stask overflow all other MRI tests pass so far (for some weird reason)
<Aethenelle>
*module tests that is...
<headius>
ok
<headius>
enebo: I'll run tests and push this if it's good
<headius>
resolved super calls are 4x faster than 1.7 in a simple test
<headius>
they optimize like any call now
<enebo>
headius: I would expect them to behave like a call
<enebo>
hah yeah
<headius>
yeah
<headius>
inlining, arity-fixing, all good
<Aethenelle>
rubyspec has two failures in module tests. Module#prepend throws a NoMethodError when there is no more superclass and Module#prepend prepends multiple modules in the right order
<headius>
one of these things will turn out to be our perf dark matter
<Aethenelle>
one of the rubyspec problems is equivalance testing iirc.
subbu has quit [Ping timeout: 255 seconds]
Aethenelle has quit [Quit: Aethenelle]
zorak8 has quit [Ping timeout: 258 seconds]
thsig has joined #jruby
thsig_ has quit [Ping timeout: 245 seconds]
Fofrik has quit [Quit: Connection closed for inactivity]
zorak8 has joined #jruby
Aethenelle has joined #jruby
<headius>
Aethenelle: how so?
<Aethenelle>
lemme check the backlog real fast
<Aethenelle>
ahh... one sec...
<Aethenelle>
Module#prepend prepends multiple modules in the right order FAILED
<Aethenelle>
Expected [:c, :m1]
<Aethenelle>
to equal [:c, :m2, :m1]
<Aethenelle>
.... nvm....
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Aethenelle>
i already fixed some of that in test_prepemd_module_ancestors in the MRI test suite yesterday
subbu has joined #jruby
<Aethenelle>
too much code w/out enough sleep...
<byteit101>
enebo: I have a one liner to do the trick, though its rather long line. How long should I make the lines?
johnsonch_afk is now known as johnsonch
Aethenelle has quit [Client Quit]
<enebo>
byteit101: I don’t know if we ever came up with a guideline on ruby side so we are probably more closer to 80 columns
<enebo>
byteit101: but for Java we are 110
<byteit101>
I'll wrap this then :) 249
<enebo>
byteit101: no doubt multiiple variables will make it easier to read as well :)
oblutak has left #jruby [#jruby]
<byteit101>
yea, I'll submit this later as I have to run now
colinsurprenant has quit [Quit: colinsurprenant]
havenwood has quit [Remote host closed the connection]
colinsurprenant has joined #jruby
mister_solo has joined #jruby
colinsurprenant has quit [Client Quit]
havenwood has joined #jruby
elia has quit [Ping timeout: 272 seconds]
elia has joined #jruby
Aethenelle has joined #jruby
<Aethenelle>
cool... I can still reach the airport wifi from the plane while we're boarding...
elia has quit [Read error: Connection reset by peer]
elia has joined #jruby
<Aethenelle>
byteit101: if it's the kind of one liner I tend to write, you should probably use do ... end if possible instead of {}...
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/BKnoIg
<JRubyGithub>
jruby/master cd6c331 Charles Oliver Nutter: Indy binding for class super plus opto for scopes around super....
JRubyGithub has left #jruby [#jruby]
<headius>
enebo, subbu: it's in
johnsonch is now known as johnsonch_afk
<enebo>
headius: coolio
<headius>
resolved supers won't deopt and will bind directly now
<headius>
check that one off the JIT to-do list
elia has quit [Read error: Connection reset by peer]
<enebo>
headius: no doubt this will help rails quite a bit
<subbu>
k
<headius>
I think I might try to do simple arity-splitting for small optional arg lists
<enebo>
headius: they have pretty long super chains and I think most are resolvable
<headius>
if they're resolvable that will be great
<headius>
oops
elia has joined #jruby
<headius>
compile error :-(
mister_solo has quit [Ping timeout: 260 seconds]
viking has quit [Remote host closed the connection]
<enebo>
FIX IT
<headius>
I guess
benlovell has joined #jruby
<headius>
fixed
<headius>
I was going to make this refactoring anyway
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/wcQvbA
<JRubyGithub>
jruby/master a0a91cf Charles Oliver Nutter: Bifurcate super call sites.
JRubyGithub has left #jruby [#jruby]
<enebo>
yay
<headius>
funny thing, structuring my indy logic using OO is better than doing all as a bunch of procedures and structs
pietr0 has joined #jruby
<enebo>
yay
<headius>
all call sites share 90% of their indy logic now
_elia has joined #jruby
<headius>
I shall remain sane as a result
Aethenelle has quit [Quit: Aethenelle]
elia has quit [Ping timeout: 250 seconds]
benlovell has quit [Ping timeout: 255 seconds]
<headius>
wow
<headius>
either I'm doing something wrong, or red/black warms up faster and executes faster on master
<headius>
it's at least on par, which is fantastic considering the JIT is so young
<headius>
exciting times
elia has joined #jruby
_elia has quit [Ping timeout: 265 seconds]
_elia has joined #jruby
elia has quit [Ping timeout: 258 seconds]
e_dub has quit [Quit: ZZZzzz…]
<lopex>
numbers!
<subbu>
headius, not true for me on java 7
elia has joined #jruby
_elia has quit [Read error: Connection reset by peer]
thsig has quit [Remote host closed the connection]
elia has quit [Ping timeout: 245 seconds]
elia has joined #jruby
zorak8 has quit [Ping timeout: 265 seconds]
nirvdrum has quit [Ping timeout: 265 seconds]
<imperator>
so, truffle gonna make it into jruby?
<lopex>
it already has
<enebo>
imperator: It is already in JRuby as a backend
<imperator>
oh? cool
thsig has joined #jruby
iamjarvo has joined #jruby
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
calavera has joined #jruby
mister_solo has joined #jruby
<chrisseaton>
imperator: don't get too excited - you won't be able to use it for anything real for a while
<enebo>
chrisseaton: no shit…implement param of rand :)
<enebo>
chrisseaton: I kid but I was just trying to invoke bench/bench_red_black.rb
<enebo>
param 1 of rand
<chrisseaton>
I'll add red/black and see how it goes
<chrisseaton>
which one are you using?
<enebo>
bench/bench_red_black.rb in our repo
elia has quit [Ping timeout: 256 seconds]
<enebo>
chrisseaton: It will be exciting when you guys can run some of these scripts without mods. I will try and do comparisons when I can and give feedback if something is bad (or good)
_elia has joined #jruby
<chrisseaton>
for every new benchmark there's always some new slight variation of a core library method we need - I wouldn't say we need mods though - we modify Truffle, not the benchmarks
<enebo>
chrisseaton: oh I am remembering back I thought to when you did change some things to for loops?
mister_solo has quit [Ping timeout: 256 seconds]
thsig has quit [Ping timeout: 245 seconds]
<chrisseaton>
don't think so - must have been something else
<enebo>
ok
<chrisseaton>
but what I should get running is the benchmark gem