<chrisseaton>
you can just write a loop that does harness_sample(harness_input))
<subbu>
i think i have the same version .. with all the tests and early exits.
<subbu>
which means it is doing the right thing.
<chrisseaton>
I've seen it report errors before when we had bugs, so it seems to do the right thing
<subbu>
headius, so, whatever was broken with deltablue in the old jit is fixed in the new jit then.
<subbu>
could be invokedynamic weirdness.
<chrisseaton>
on 1.7 for me this is slower with indy than without
<chrisseaton>
deltablue is tricky as it's just large enough to not be able to get your head around what is going on at each line
iamjarvo has joined #jruby
havenwood has quit [Remote host closed the connection]
<subbu>
on master, much faster with invokedynamic than without.
Hobogrammer has joined #jruby
<subbu>
i am on java7
phrinx has quit [Remote host closed the connection]
<chrisseaton>
Truffle doesn't do very well on deltablue actually, I need to figure it out
<headius>
subbu: cool
<headius>
subbu: deltablue should be even faster with this commit
<headius>
ok, I have other stuff running now
<headius>
redblack still seems to be 2x
<headius>
slower
<subbu>
k
<headius>
fib is like 50% slower
<headius>
1.5x
<headius>
subbu: I'll push this in a moment
<headius>
going to check profile for simple bench quick to see if there's something stupid I'm doing
<headius>
hmm, it looks ok for allocation profile
<headius>
MUCH better with no arg boxing
<headius>
hmm...new version doesn't have any of the special fixnum logic the old one did
<headius>
a + 2 would not use a fixnum object for 2, which is lighter
<headius>
that was a one-off optimization for binary operand with second param a literal number
josh-k has quit [Remote host closed the connection]
josh-k has joined #jruby
<headius>
subbu: one thing I do see is that that "nth scope module" instruction is emitted all the time
<headius>
even if the module isn't used
<headius>
that probably would fall out with dce
<headius>
subbu: DCE should be safe to run any time, right?
<subbu>
headius, you mean the current scope module init?
<headius>
yes
<subbu>
yes.
<subbu>
i thought it is currently enabled.
<headius>
unconditionally done in build process
<headius>
it is not because of temp init
<headius>
they disappear and JIT breaks
<headius>
but I can put it before EnsureTemps, eh?
<subbu>
actually put it before AddLoadStore..
<subbu>
it is okay to run as long as you add those inits after dce runs .. but put dce before AddLoadStore..
josh-k has quit [Ping timeout: 244 seconds]
<headius>
ok
<headius>
the emitted code for fib is damn close to the old JIT now
<headius>
this will be REALLY exciting when we can specialize again...I can have indy call sites bind raw primitive values straight through
<headius>
groundwork being laid now
<subbu>
nirvdrum, can you share the code that was generating that stack overflow ... i lost that snippet. i'll try to take a look in the next couple days.
<headius>
hmm
<headius>
DCE removed ScopeModule but not CurrentScope
diegoviola has quit [Remote host closed the connection]
johnsonch is now known as johnsonch_afk
<headius>
er no
<headius>
I am wrong
<headius>
I think this is something I'm doing...hmm
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<headius>
oh I see
<headius>
oooo closer... another 10% reduction in fib
<headius>
just for removing getCurrentScope...that stuff is surprisingly expensive
<headius>
I'm now only about 25% slower than old JIT
iamjarvo has joined #jruby
<headius>
the temp init could be affecting this too
<headius>
that's an extra field access per call
<headius>
at minimum
johnsonch_afk is now known as johnsonch
<headius>
subbu: I remembered one thing JVM6 support does poorly: method invocation looks up every time
<headius>
I just need to rework the call site generation it does to cache something
<subbu>
headius, ok.
<headius>
I need to put together a list of things old JIT did that new one doesn't yet
<subbu>
also discovered that dyn-scope removal code generates a lot of new temp vars .. looking at fib code, i now see it using 8 tmps whereas i was certain it had much fewer before. will look at it tomorrow.
<headius>
* fixnum operations avoid fixnum object for literal argument in many cases
<headius>
* fixnum boolean comparisons like "if a < 2" avoid fixnum object for 2 and do a direct boolean compare in the indy logic
<headius>
subbu: ahh ok
<headius>
some of that may be for the unconditional block/proc load that seems to get inserted in many scopes
<headius>
receive_block I think
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/Kdji1g
<JRubyGithub>
jruby/master d8096e2 Subramanya Sastry: Code cleanup for AddCallProtocolInstructions...
JRubyGithub has left #jruby [#jruby]
<headius>
I think the boolean check may be to blame here more than anything
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<headius>
the < check in fib does a full slow call to :< and gets a RubyBoolean back, then calls isTrue on it, then does the branch
<headius>
bleh
<headius>
that's : <
<headius>
subbu: I had started trying to add unboxed boolean logic to the unboxing pass
<headius>
that would be useful to have before numeric unboxing, so I could use primitive booleans more frequently in the JIT
tylersmith has joined #jruby
<headius>
as it is now all boolean operations have to get a RubyBoolean and query it
<headius>
that combined with literal fixnum op improvements probably will make up the last 25-30% on fib
<headius>
subbu: I'm going to finish this up and push momentarily, but an empty method bench is identical in new and old JIT
<headius>
so at least we have simple method opto pretty close overhead-wise
<headius>
I'm happy this is working... ciao!
<subbu>
ok .. in an out here ..
<subbu>
will take a look tomorrow at other things.
josh-k has joined #jruby
<headius>
ok
<headius>
this is very exciting :-)
<headius>
we're finally at the point where we can play with opto
colinsurprenant has joined #jruby
<subbu>
actually tmp-var-opt was not running at all ... verifying now ... I broke it while messing with pass dependencies ..
<headius>
ok
<headius>
that's another obvious difference looking at the bytecode...lots more loads and stores
<headius>
I'd expect Hotspot to eliminate all that though
<subbu>
aha .. suddenly the lost interp perf. is coming back :) .. i had been baffled why it had slowed down relative to 1.7 branch IR interp.
<headius>
oh nice!
<headius>
it occurs to me I could probably use this logic to handle multiple-arity methods
<headius>
I just need to special case the opt-arg logic for each valid arity
<headius>
it will also work to make direct kwarg entry points
<headius>
just need to save off a handle to the kwarg version that passes arguments as a param list of k/v pairs
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/d-d1wQ
<JRubyGithub>
jruby/master fa44bc1 Subramanya Sastry: Dont force build CFG - let dependencies take care of it....
JRubyGithub has left #jruby [#jruby]
<headius>
subbu: fixed-arity logic is in
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/WqtjTA
<JRubyGithub>
jruby/master 31f7926 Charles Oliver Nutter: Dirt simple fixed-arity support in new JIT....
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to truffle-head: http://git.io/B0hHiA
<JRubyGithub>
jruby/truffle-head e6fc529 Chris Seaton: [Truffle] Use new LoopNode for while (gives us OSR for the first time).
JRubyGithub has left #jruby [#jruby]
<headius>
woohoo
<headius>
OSR
<headius>
bench_base64 is faster with new JIT
<headius>
oh wait no...still just slightly slower
<headius>
but we're really close on all these now
phrinx has joined #jruby
brettporter has joined #jruby
brettporter has joined #jruby
brettporter has quit [Ping timeout: 258 seconds]
Aethenelle has joined #jruby
iamjarvo has joined #jruby
<headius>
subbu: another bug... if a call site encounters an interpreted method that has not yet been jitted, it never tries to rebind to jitted version after that
<headius>
I'm fixing by having InterpretedIRMethod have a SwitchPoint indicating that it has switched to JIT
<headius>
those sites will rebind to the jitted version then
Aethenelle has quit [Quit: Aethenelle]
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Hobogrammer_ has joined #jruby
Hobogrammer has quit [Ping timeout: 256 seconds]
pgokeeffe has quit [Ping timeout: 260 seconds]
towski has quit [Read error: Connection reset by peer]
<headius>
subbu: there are issues with interpreted switching to JIT that will require threshold=0 for good perf numbers right now
<headius>
my call site binding is super naive still and needs some rework...now JIT will invalidate the interpreted version, but I am currently only rebinding sites once
<subbu>
headius, ok .. is this switching issue different from the old runtime?
josh-k has quit [Remote host closed the connection]
josh-k has joined #jruby
<headius>
yes...the old logic had two metrics at the call site: number of types encountered (allowed up to 6 in PIC) and number of rebinds (allowed up to 1000 before the site bailed out to a monomorphic cache)
<headius>
neither of those are active for new JIT...it either binds the method or it binds a fallback that does slow-path lookup every time
<headius>
and it never rebinds because the fallback is also the slow-path lookup (i.e. fallback does not rebind)
<headius>
I will have to think about how to structure the call sites a bit better before I can fix this, but I'm trying to do a simple fix now
<subbu>
ok ... i am heading to bed shortly, but can pick up the threads tomorrow.
josh-k has quit [Read error: Connection reset by peer]
<headius>
ok
<headius>
I'll push what I have shortly and call it a night...but this was a big day
colinsurprenant has quit [Quit: colinsurprenant]
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rtyler>
rats, I missed him
<rtyler>
pointer arrays in ffi is hard >_<
<headius>
hard?
<headius>
I guess you have to allocate an block of memory N * pointer width and populate it
<rtyler>
there are no helpers to give you a stack allocated pointer?
<rtyler>
turns out a base address of 0x0 isn't a good idea :p
<headius>
I don't know about stack allocated versus heap allocated in FFI
<headius>
does it have to be stack allocated?
<rtyler>
let me rephrase, I need to create a pointer to an array of ints
<headius>
ahhhh ok
JRubyGithub has joined #jruby
<JRubyGithub>
jruby/master 6cf0535 Charles Oliver Nutter: Use MethodType to track multiple signatures for jitted method.
<JRubyGithub>
jruby/master e54dc35 Charles Oliver Nutter: Make interp method => jit call path use 0-3 specific arity.
<JRubyGithub>
[jruby] jrubyci pushed 2 new commits to master: http://git.io/r-4mQg
JRubyGithub has left #jruby [#jruby]
<headius>
I think you just allocate chunk of memory that's as wise as you need
<headius>
there's wrappers for it, or you could just call malloc
<headius>
alloca might work, I don't know
josh-k has joined #jruby
<headius>
seems unlikely because of the layers involved
<rtyler>
hrm
<headius>
I have to go though...have fun :-)
<rtyler>
:*(
<headius>
subbu: FYI, perf issue I mentioned above *does* affect red/black because something in the script fails to compile
<headius>
so everything you're seeing is jitted perf, which isn't getting proper indy treatment
<headius>
lazily jitted that is
<headius>
night all...big progress today
<subbu>
ok ... good night.
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/hlFMDw
<JRubyGithub>
jruby/master a33c383 Subramanya Sastry: Ensure CFG is built at the end of IRScope.initScope()...
JRubyGithub has left #jruby [#jruby]
johnsonch is now known as johnsonch_afk
towski has quit [Remote host closed the connection]
josh-k has quit [Read error: Connection reset by peer]
brettporter has quit [Ping timeout: 256 seconds]
dbussink has joined #jruby
tylersmith has quit [Remote host closed the connection]
yfeldblum has quit [Ping timeout: 265 seconds]
johnsonch_afk is now known as johnsonch
JohnBat26 has joined #jruby
sluukkonen2 has joined #jruby
benlovell has joined #jruby
johnsonch is now known as johnsonch_afk
DomKM has quit [*.net *.split]
Scorchin has quit [*.net *.split]
cpuguy83 has quit [*.net *.split]
sluukkonen1 has quit [*.net *.split]
fridim_ has joined #jruby
rsim has joined #jruby
robbyoconnor has joined #jruby
pchalupa has joined #jruby
ephemerian has joined #jruby
Usuario has joined #jruby
skade has quit [Ping timeout: 265 seconds]
erikhatcher has joined #jruby
Usuario is now known as obs
johnsonch_afk is now known as johnsonch
robbyoconnor has quit [Remote host closed the connection]
robbyoconnor has joined #jruby
johnsonch is now known as johnsonch_afk
robbyoconnor has quit [Ping timeout: 265 seconds]
thsig has joined #jruby
mbj has joined #jruby
DomKM has joined #jruby
Scorchin has joined #jruby
cpuguy83 has joined #jruby
vtunka has joined #jruby
elia has joined #jruby
kares has joined #jruby
josh-k has joined #jruby
DomKM has quit [*.net *.split]
Scorchin has quit [*.net *.split]
cpuguy83 has quit [*.net *.split]
brettporter has joined #jruby
DomKM has joined #jruby
Scorchin has joined #jruby
cpuguy83 has joined #jruby
brettporter has quit [Ping timeout: 265 seconds]
kares has quit [Ping timeout: 258 seconds]
johnsonch_afk is now known as johnsonch
yfeldblum has joined #jruby
dumdedum has quit [Quit: foo]
kares has joined #jruby
johnsonch is now known as johnsonch_afk
DomKM has quit [*.net *.split]
Scorchin has quit [*.net *.split]
cpuguy83 has quit [*.net *.split]
pellis has joined #jruby
<pellis>
hi all - 2 questions. what's the fastest json gem to use in order to parse/dump
<pellis>
and also - how do i profile ruby code under jruby?
drbobbeaty has joined #jruby
Hobogrammer_ has quit [Ping timeout: 265 seconds]
thsig has quit [Remote host closed the connection]
yfeldblum has quit [Remote host closed the connection]
thsig has joined #jruby
yfeldblum has joined #jruby
tenderlove has joined #jruby
thsig_ has joined #jruby
thsig has quit [Ping timeout: 244 seconds]
kares has quit [Ping timeout: 272 seconds]
tenderlove has quit [Ping timeout: 244 seconds]
phrinx has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
phrinx has quit [Ping timeout: 260 seconds]
robbyoconnor has joined #jruby
johnsonch_afk is now known as johnsonch
robbyoconnor has quit [Excess Flood]
postmodern has quit [Quit: Leaving]
johnsonch is now known as johnsonch_afk
kaawee has joined #jruby
robbyoconnor has joined #jruby
robbyoconnor has quit [Excess Flood]
cpuguy83 has joined #jruby
DomKM has joined #jruby
Scorchin has joined #jruby
dumdedum has joined #jruby
Ruber has joined #jruby
<Ruber>
Hello, is there anybody ?
<Ruber>
I'd like to get recommendation about jopenssl
robbyoconnor has joined #jruby
brettporter has joined #jruby
brettporter has quit [Ping timeout: 256 seconds]
johnsonch_afk is now known as johnsonch
shellac has joined #jruby
johnsonch is now known as johnsonch_afk
shellac has quit [Client Quit]
shellac has joined #jruby
phrinx has joined #jruby
Ruber has quit [Ping timeout: 246 seconds]
phrinx has quit [Ping timeout: 246 seconds]
kaawee has quit [Ping timeout: 250 seconds]
toshetm has joined #jruby
benlovell has quit [Ping timeout: 258 seconds]
drbobbeaty has joined #jruby
johnsonch_afk is now known as johnsonch
benlovell has joined #jruby
johnsonch is now known as johnsonch_afk
thsig_ has quit [Remote host closed the connection]
thsig has joined #jruby
robbyoconnor has quit [Quit: Konversation terminated!]
benlovell has quit [Ping timeout: 246 seconds]
erikhatcher has quit [Quit: erikhatcher]
fntzr has joined #jruby
fntzr has quit [Remote host closed the connection]
thsig_ has joined #jruby
kaawee has joined #jruby
thsig has quit [Ping timeout: 245 seconds]
brettporter has joined #jruby
brettporter has joined #jruby
tenderlove has joined #jruby
brettporter has quit [Ping timeout: 240 seconds]
johnsonch_afk is now known as johnsonch
johnsonch is now known as johnsonch_afk
tenderlove has quit [Ping timeout: 255 seconds]
kaawee has quit [Ping timeout: 250 seconds]
shellac has quit [Ping timeout: 265 seconds]
shellac has joined #jruby
kaawee has joined #jruby
tcrawley-away is now known as tcrawley
benlovell has joined #jruby
erikhatcher has joined #jruby
bbrowning_ is now known as bbrowning
benlovell has quit [Ping timeout: 244 seconds]
yfeldblum has quit [Remote host closed the connection]
benlovell has joined #jruby
<headius>
good morning
<headius>
pellis: I've heard good things about jrjackson
etehtsea has joined #jruby
<headius>
for profiling, you can use most JVM profiling tools, or we provide --profile flags at command line
etehtsea has quit [Client Quit]
etehtsea has joined #jruby
etehtsea has quit [Max SendQ exceeded]
<pellis>
headius: yep. i used jrjackson eventually.
<pellis>
i'm running hadoop data processing which is based on accessing deeply nested hashes (from JSON), and i just read your rant about hashes
rsim has quit [Quit: Leaving.]
<pellis>
it *does* run embarrasingly slow :(
etehtsea has joined #jruby
<pellis>
some 1000 hashes per sec or less
etehtsea has quit [Client Quit]
<pellis>
each hash is nested to up to 5 levels, has 43 nested field lookups. hadoop node is m1.xlarge
jruby687 has joined #jruby
rcvalle has joined #jruby
<jruby687>
I have installed jruby1.7.16 but when i run command "jruby -S gem install win32-api", i get a problem :Error installing win32-api: ERROR: Failed to build gem native extension.
josh-k has quit [Remote host closed the connection]
josh-k has joined #jruby
thsig_ has quit [Remote host closed the connection]
<usebrn>
hi all
<usebrn>
I believe I found another source of leak
<usebrn>
filenoDescriptorMap
<usebrn>
static map, to which descriptors are regiestered and unregistered
<usebrn>
I can see that within one run of SC 3 descriptors remain in this map
<usebrn>
So there are too leaks in my server, and both of them seems to be on jruby side
<usebrn>
I will try do report bug today if I manage to find time
thsig has joined #jruby
<usebrn>
one is connected with leakings when different threads use the same container, and termination probably doesn't unlink some references from other thread which were using SC
<headius>
usebrn: ahh ok...a heap dump will let us see what's holding on to references
<headius>
filenoDescriptorMap is a known problem :-\
<headius>
it is gone for 9k but not easy to remove in 1.7.x
<usebrn>
and the second one with the fact that, when using custom Writer for stdout or stderr resources are also not released
<usebrn>
hmmm
<usebrn>
is there some version of 9k which I could use in production already ?
<headius>
not really...we're getting close to a previewable state
<headius>
filenoDescriptorMap hmmm
<headius>
maybe it could be weak
<usebrn>
when I check calls to register and unregister I can see that after each cycle in which I create SC and terminate it, 3 descriptors are left each time
<headius>
well that's not too bad...we can figure out which ones they are
<headius>
that sounds like something we can fix
<usebrn>
the first 3 which are being registered
<usebrn>
I havent traced the whole stack, just put breakpoints in register and unregister methods
<usebrn>
I will try to send a code which reproduces all these strange behaviours
<usebrn>
and these 3 descriptors show up in the map when method parse is called
<usebrn>
on ScriptingContainer
<usebrn>
ok, all of them are put to map on parse method actually, but it has to be different stage, as stack is several times shorter
<usebrn>
ok I can see it now
<usebrn>
it is in RubyGlobalClass
erikhatcher has quit [Quit: erikhatcher]
<usebrn>
creation of RubyIO objects for STDIO.IN, STDIO.OUT and STDIO.ERR
<usebrn>
perhaps I should call something to unregister them
<usebrn>
sc.unset or something, but I cannot see proper method in ScriptingContainer API
<usebrn>
this is really strange to register something on object creation
<usebrn>
it seems that these descriptors are put to the map on ChannelDescriptor creation
<usebrn>
and these descriptors correspond to IN, OUT and ERR
thsig has quit [Remote host closed the connection]
n1ftyn8_ is now known as n1ftyn8
iamjarvo has joined #jruby
thsig has joined #jruby
<usebrn>
headius: do you have some ideas how can I unregister it without patching jruby ?
iamjarvo has quit [Client Quit]
lance|afk is now known as lanceball
ludyte has joined #jruby
johnsonch_afk is now known as johnsonch
brettporter has joined #jruby
enebo has joined #jruby
fridim_ has quit [Ping timeout: 255 seconds]
fridim_ has joined #jruby
brettporter has quit [Ping timeout: 255 seconds]
subbu has joined #jruby
<headius>
enebo: good morning
<headius>
I'm going to temporarily make the JVM6 call sites use CachingCallSite
<enebo>
headius: heya
<enebo>
ok
<headius>
until I can figure out a way to generate unique call site logic without duplicating a crapload of code every time
rsim has joined #jruby
<headius>
just trying to get some caching into JVM6 so it's not so slow
e_dub has joined #jruby
<headius>
enebo: I don't know if you saw but I pushed fixed-arity stuff last night
<enebo>
headius: just reading email atm
<headius>
ok
<enebo>
headius: do you have numbers?
<headius>
yeah, everything's much better
<headius>
not quite old JIT yet but we'll iterate on bits and pieces that remain
<enebo>
headius: for your favorite benchmark what is the difference?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/xEtWjA
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
jruby/master 67f4a90 Charles Oliver Nutter: Use a call site cache for JVM6 generated call sites for now.
<headius>
about 2x
<headius>
it's only about 30% slower than old JIT now
<enebo>
ok that is better…run deltablue
<lopex>
go go!
oblutak has joined #jruby
<headius>
I want to get subbu's deltablue script
<subbu>
it is the same one that chris pasted y'day .. but, let me gist it. one sec.
<enebo>
headius: did old JIT do really well with for blocks?
<headius>
not really well, no
colinsurprenant has joined #jruby
tenderlove has joined #jruby
<enebo>
headius: yeah I am guessing this is why IR is so much better. That version of the script I think has some hot path for blocks
<enebo>
headius: for IR is just a simple jump
tenderlove has quit [Remote host closed the connection]
tenderlove has joined #jruby
<headius>
subbu: FYI, that deltablue script almost uses entire default 500MB heap...bumping heap size probably would improve perf
<usebrn>
headius: was it you who wrote Handling and managing IO in jruby ?
<headius>
wrote what exactly? the IO subsystem?
<usebrn>
RubyIO, ChannelDescriptor etc
<usebrn>
the problem with this map is that, stdin, stdout, stderr have autoclose flag put to false
<usebrn>
set to false
<usebrn>
and when finalizing, it misses branch in which unregister is located
<usebrn>
this is in finish method of ChannelDescriptor
<usebrn>
that is why they are never unregistered, but I dont know why they have autoclose set to false
iamjarvo has joined #jruby
<usebrn>
and why there is not api to close them manually if they have autoclose set to false
<usebrn>
this flag is set in RubyIO constructor taking Ruby and STDIO parameters
<usebrn>
and there is a comment
<usebrn>
<usebrn>
// never autoclose stdio streams
shellac has quit [Quit: Computer has gone to sleep.]
<usebrn>
so how these streams are supposed to be actually closed? I assume this is responsibility someone who uses these streams, but in that case these descriptors will be never removed from the map.
<usebrn>
so I passed Writer to ScriptingContainer, and after closing it, Ruby didn't unregister them. I believe it is a bug, not sure how can I hack it out so my server didn't hang because of resources leak.
<headius>
usebrn: well, we could just unregister them and not close them
<headius>
that would seem like a safe thing to do at runtime teardown
<enebo>
ok so I will finish up end/begin logic and go back towards refactoring towards instantiated interpreter (and then arity splitting it)
<headius>
ok
<subbu>
enebo, headius ok there you go. ^
<enebo>
although I might hack some shit out after seeng that commit :)
<headius>
InterpretedIRMethod has 0-3 arg versions of call now
<headius>
it needed it to allow calls to pass args through to jitted version without boxing
<enebo>
headius: calls back into boxed INTERPRET_METHOD though
<headius>
yes
<enebo>
ok
<headius>
only helps jitted right now
<enebo>
headius: yeah figured since we share at that point
colinsurprenant has quit [Quit: colinsurprenant]
<headius>
btw, I realized one thing that might be impacting startup on 1.7.16 with indy... JIT invalidates the class hierarchy a method is in
<headius>
I was working on a better way for master, wherein an InterpretedIRMethod has its own switchpoint that gets invalidated when the JIT has run
<headius>
so anything that cached it would bail out and recache based on jitted version, but other methods cached from that class won't also be invalidated
<headius>
I haven't rigged it all up...indy stuff for 9k has a lot of room to be tuned
brettporter has quit [Ping timeout: 272 seconds]
<headius>
subbu: awesome
<enebo>
headius: I am somewhat confused…new JIT code hangs off interpretedIRmethod…should it really be invalidating anything?
<headius>
if it doesn't, any call site that has cached the interpreted method will never do a direct indy dispatch to the jitted version
<headius>
they'll only ever go through DynamicMethod.call and the logic that checks if things are jitted yet
<headius>
i.e. nothing inlines
<enebo>
ah yeah
<enebo>
ok
colinsurprenant has joined #jruby
cprice404 has joined #jruby
thsig has quit [Remote host closed the connection]
<chrisseaton>
enebo: we're having some trouble getting the detailed source location information that we need out of the parser. I think this fundamentally comes down to the token being generated and the parser requesting a source location at different times, so the two sometimes just don't match up
<chrisseaton>
enebo: I'm going to try creating a copy of the lexer and parser, in the Truffle package, with real Token objects
<enebo>
chrisseaton: yeah if I had to guess I would say most confused portion of it will be in heredoc processing
<chrisseaton>
enebo: just letting you know so you don't think we've gone rogue - it's just an experiment
<enebo>
chrisseaton: no I understand. If you are interested in simpler lexer you can also look at ripper source
<chrisseaton>
enebo: I think you used to have Token objects but removed them for warmup performance didn't you?
<enebo>
chrisseaton: It is was I was basnig my on-hold lexer rewrite on
<enebo>
chrisseaton: trying to remove extra allocation
<enebo>
chrisseaton: Eventually all identifiers will be backed by source array to eliminate 2x string creation
<enebo>
chrisseaton: At least I am hoping that is reasonable since it means all source will end up pinned if the identifier or string literal is living
iamjarvo has quit [Remote host closed the connection]
<enebo>
chrisseaton: If you go back far enough in source we used to have the jrubyparser full token info which would have start and end offset
<enebo>
chrisseaton: token was added for that specifically actually
<chrisseaton>
enebo: I'll consider that, but I want to merge your future changes easily
<enebo>
chrisseaton: yeah. that makes sense
<chrisseaton>
enebo: what are we going to do about ruby-parser in the future? it's very behind and hard to merge now isn't it?
shellac has quit [Quit: Computer has gone to sleep.]
colinsurprenant has joined #jruby
<enebo>
chrisseaton: It is hard but when I do a jruby-parser session I just compare diffs in our .y file in jruby and then hand change the same parts in jrubyparser. So it is painful but it is done in an hour or two
yfeldblum has joined #jruby
<enebo>
chrisseaton: over time all parser changesets dwindle to tiny changes
<chrisseaton>
but isn't the AST changing a little but here and there? the 19 stuff for example, some of things maybe
<enebo>
chrisseaton: well there is changes in both projects. in jrubyparser the ast is evolving to lose any nodes which are specific to execution
<enebo>
chrisseaton: in jruby we will be simplifying nodes over time that do not help IR generation
<enebo>
chrisseaton: Ruby side has not really been changing node names or behavior very much
<enebo>
chrisseaton: but you are right..ruby 3 might have big changes and be painful for jrubyparser
<enebo>
chrisseaton: Although with Matz not wanting to break compatibility that probably is not going to happen
rsim1 has joined #jruby
shellac has joined #jruby
rsim has quit [Read error: Connection reset by peer]
yfeldblum has quit [Ping timeout: 255 seconds]
ludyte has quit [Quit: ludyte]
rsim1 has quit [Client Quit]
iamjarvo has joined #jruby
thsig has joined #jruby
kotk has joined #jruby
vtunka has quit [Quit: Leaving]
<dfr|work>
morning all
kotk_ has quit [Ping timeout: 256 seconds]
<headius>
morning!
<dfr|work>
it's so rainy in NYC, I feel like in Seattle :)
<dfr|work>
but hopefully that'll mean a snowy winter
<enebo>
headius: I notice we only have doDebug() in interpreterirmethod for interperpreter. Seems like this is useful even with JIT on
<enebo>
Perhaps more so since it is looking at IRScope CFG which should match what JIT compiled from
havenwood has joined #jruby
nirvdrum has joined #jruby
thsig has quit [Remote host closed the connection]
tcrawley has quit [Changing host]
tcrawley has joined #jruby
lanceball is now known as lance|afk
<enebo>
headius: moved it forward before jit logic in each call method. If we have an IR-level bug without this we will not be able to see what CFG the JIT is using
<headius>
ok
<enebo>
I would sort of like to make a DebugIRMethod but that would not allow us to toggle on and off easily during execution
pchalupa has quit [Quit: Leaving]
zeroecco has joined #jruby
<enebo>
headius: actually it might make more sense if you JIT in debug callout then you can make it a switchpoint
zeroecco has quit [Client Quit]
<enebo>
headius: then interpreter will be responsible for this as well and we won’t have this logic this far up
<enebo>
headius: other reason for this is that when debug is on IC will end up eventually having a cloned CFG so interpreter debugging is accurate even if JIT is running
<enebo>
headius: but that means interp will be looking in dirrerent place for the info
<headius>
JIT in debug callout?
zeroecco has joined #jruby
<enebo>
oh JIT does not store IRScope does it?
<enebo>
or reference to the method it an actualMethod to
<enebo>
crud
<enebo>
headius: I just meant JIT could call out to a debug runtime helper to print out deubg output …
<enebo>
headius: but the check for debug mode itself could be a switchpoint
<enebo>
headius: but I think you do not have the info by the time you enter the method you generate anymore
<headius>
JIT does store IRScope now
<headius>
it's a little hacky but it's working
<enebo>
headius: ah well it can eliminate this tiny cost if you generate a simple guard to see if you are in debug mode or not
<enebo>
headius: and I think a field to know whether you have displayed this output once
<enebo>
I realize right now too that this debug output is probably broken as well if we run a method multiple times through passes (e.g. 1 for interp and 1 for JIT) since it only prints out the CFG first time and it does not redisplay the CFG after later passes
<enebo>
headius: hmmm. I will get back to you on this :) I want to make sure we always redisplay CFG if we re-run any passes. As it stands now we may only see CFG after interp run passes
<enebo>
headius: but everything else I said above is still true. JIT looks at different data than interp and we will want JIT to print out CFG it used to generate bytecode
ludyte has joined #jruby
colinsurprenant has quit [Quit: colinsurprenant]
Hobogrammer has joined #jruby
benlovell has joined #jruby
josh-k has quit [Remote host closed the connection]
benlovell has quit [Ping timeout: 272 seconds]
mbj has quit [Ping timeout: 256 seconds]
pellis has quit [Remote host closed the connection]
Hobogrammer_ has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/GHJ_pA
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
jruby/master c5994bb Benoit Daloze: [Truffle] Fix copyright years for all Java truffle files since October 1.
mbj has joined #jruby
<headius>
enebo: that seems reasonable
brettporter has joined #jruby
<headius>
I think we can do that
havenwood has quit [Ping timeout: 246 seconds]
havenwood has joined #jruby
diegoviola has joined #jruby
Hobogrammer has quit [Ping timeout: 245 seconds]
Hobogrammer has joined #jruby
shellac has quit [Ping timeout: 258 seconds]
brettporter has quit [Ping timeout: 258 seconds]
diegoviola has quit [Remote host closed the connection]
tylersmith has joined #jruby
Hobogrammer_ has quit [Ping timeout: 256 seconds]
diegoviola has joined #jruby
owenou has joined #jruby
bbrowning is now known as bbrowning_away
owenou has quit [Client Quit]
statonjr has quit [Quit: statonjr]
x1337807x has joined #jruby
mbj has quit [Ping timeout: 244 seconds]
statonjr has joined #jruby
mbj has joined #jruby
diegoviola has quit [Ping timeout: 246 seconds]
diegovio1 has joined #jruby
diegovio1 is now known as diegoviola
havenwood has quit [Remote host closed the connection]
elia has quit [Quit: Computer has gone to sleep.]
elia has joined #jruby
elia has quit [Client Quit]
lance|afk is now known as lanceball
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
colinsurprenant has joined #jruby
phrinx has joined #jruby
elia has joined #jruby
mbj has quit [Quit: leaving]
elia has quit [Quit: Computer has gone to sleep.]
ludyte has quit [Quit: ludyte]
thsig has joined #jruby
colinsurprenant has quit [Quit: colinsurprenant]
subbu is now known as subbu|lunch
colinsurprenant has joined #jruby
tenderlove has quit [Quit: Leaving...]
marr has quit [Ping timeout: 244 seconds]
ludyte has joined #jruby
dumdedum has quit [Quit: foo]
colinsurprenant has quit [Quit: colinsurprenant]
colinsurprenant has joined #jruby
colinsurprenant has quit [Client Quit]
<enebo>
hmmm I can suddenly no longer build jruby from truffle errors
subbu|lunch is now known as subbu
<headius>
hmm
<headius>
that's not good
<subbu>
mvn clean; mvn usually fixes those for me.
<enebo>
subbu: I pretty do that all the time
<subbu>
k
<enebo>
pretty/pretty much/
<enebo>
precious
<chrisseaton>
I'll take a look
havenwood has joined #jruby
iamjarvo has joined #jruby
<chrisseaton>
enebo: c5994bb builds for me - are you still having problems?
<mberg>
There may be a prettier way, but that should work.
subbu|busy is now known as subbu
<dfr|work>
mberg, yea, that's exactly what I ended up doing :)
<dfr|work>
just for the record, once I'm done ditching jruby-rack and therefore will stop complaining about it, I'll start the process of ditching activerecord-jdbc-adapter and start complaining about it ;)
<dfr|work>
I'll have to ask kares how he feels about it ;)
<rtyler>
brixen: can you circulate that to your Rubinius buddies? :D
<dfr|work>
although I expect him to wonder why he ought to care