phrinx has quit [Remote host closed the connection]
havenwood has quit [Ping timeout: 250 seconds]
_djbkd has quit [Remote host closed the connection]
nirvdrum has quit [Ping timeout: 246 seconds]
batasrki has quit [Quit: leaving]
brauliobo has quit [Ping timeout: 272 seconds]
havenwood has joined #jruby
_djbkd has joined #jruby
tarcieri_ is now known as tarcieri
yfeldblum has quit [Ping timeout: 246 seconds]
mdedetrich has joined #jruby
thedarkone2 has quit [Quit: thedarkone2]
yfeldblum has joined #jruby
skade has joined #jruby
skade has quit [Client Quit]
pawnbox has joined #jruby
Cyrus1 has quit [Read error: Connection reset by peer]
Cyrus1 has joined #jruby
pitr-ch has joined #jruby
rsim has joined #jruby
yfeldblum has quit [Ping timeout: 246 seconds]
skade has joined #jruby
rsim has quit [Quit: Leaving.]
rsim has joined #jruby
yfeldblum has joined #jruby
bbrowning_away has quit [Remote host closed the connection]
bbrowning_away has joined #jruby
kwando has quit [Ping timeout: 264 seconds]
samphippen has joined #jruby
TheWhip has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
_djbkd has quit [Quit: My people need me...]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
<GitHub32>
[jruby-openssl] mkristian opened issue #73: when the security provider can not be verify creating of new ciphers is very slow http://git.io/vcnYB
TheWhip has quit [Remote host closed the connection]
<projectodd-ci>
* eregontp: [Truffle] Remove duplicate specializations as we have ImplicitCast int => long.
<headius>
woo
Aethenelle has joined #jruby
<GitHub194>
[jruby-openssl] mkristian pushed 1 new commit to more-default-locations: http://git.io/vcc6h
<GitHub194>
jruby-openssl/more-default-locations 43be800 Christian Meier: avoid verifying the security provider when creating a cipher instance...
<GitHub170>
[jruby-openssl] mkristian closed issue #73: when the security provider can not be verify creating of new ciphers is very slow http://git.io/vcnYB
<GitHub147>
[jruby-openssl] mkristian pushed 1 new commit to master: http://git.io/vccig
<GitHub147>
jruby-openssl/master f1ca23c Christian Meier: avoid verifying the security provider when creating a cipher instance...
jensnockert has joined #jruby
colinsurprenant has joined #jruby
samphippen has quit [Ping timeout: 250 seconds]
jensnockert has quit [Read error: Connection reset by peer]
enebo has joined #jruby
jensnockert has joined #jruby
jensnockert has quit [Remote host closed the connection]
<headius>
enebo: did you get full rescues to optz yesterday?
<headius>
I believe I have blocks jitting in a somewhat hacky way
<enebo>
headius nope. It is more complicated to figure out but I will try and get it this morning
subbu_ has joined #jruby
<headius>
ok. I'm going to test csv with block jitting and see how it looks, but I'll leave postfix rescues in place
<headius>
it turned out easier than i thought but I duplicated a lot of infrastructure used for method JIT
<headius>
that will need to be cleaned up
<enebo>
the rescue part of AST has always been confusingly weird since it chains and rescue body and rescue itself copies the same node
Aethenelle has quit [Quit: Aethenelle]
samphippen has joined #jruby
<headius>
ok, looks like it's working but it doesn't run passes
<headius>
so I have to add that
<headius>
so I don't get rescue optimization
colinsurprenant has quit [Quit: colinsurprenant]
<headius>
not in that order
<headius>
enebo: yeah
<headius>
this particular case should be a single chained rescue though
<headius>
that would be an easy one to do at first, no? if only one rescue body and it is a simple expression
<enebo>
no not really
subbu_ has quit [Quit: Leaving]
<enebo>
we call buildEnsureInternal before we call buildRescueInternal (which looks for opt) so I need to figure out more than just whether it has one rescue child
<enebo>
although the rescue child is not hard
<headius>
ahh, ick
<headius>
ok
<headius>
well the "end rescue f" hack is pretty minor
<headius>
and that will be the only diff from stock csv when I'm done
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<enebo>
headius: I do want to figure this out and possibly clean it up
<enebo>
headius: so you JITting of blocks is what exactly? how did you resolve the parent scope part?
<headius>
I don't
<headius>
they still require full protocol even when jitted so all I'm doing is letting JIT run and getting a handle to the resulting method
<headius>
same as I would if I were jitting the surrounding scope
<enebo>
headius: so is this just for JIT’ing hash with lambdas early?
<headius>
well, this should work for any escaped closure
<enebo>
oh
<enebo>
headius: so aftr n invocations if closure does not capture it will JIT?
<headius>
captures are irrelevant...closure will be assimilated
<enebo>
heh
<headius>
the captures are just sitting out there in a dynscope
<headius>
I just use the same dynscope
<enebo>
headius: ok so I think this all works out because methods will not convert vars to temp vars if a closure is present
<headius>
well, I don't have it running passes yet :-)
<headius>
it may actually do tmp var loading and blow this up
<enebo>
headius: ah yeah but I think it is still fine for the temp vars part not eliminating a dynscope
<enebo>
headius: or it will do load/stores to correct things by time closure executes
<enebo>
headius: in either case it should have dynscope set up by the time you call the closure so that part at least should be fine
camlow32_ has quit [Read error: Connection reset by peer]
cremes has joined #jruby
camlow32_ has joined #jruby
camlow325 has quit [Ping timeout: 246 seconds]
bbrowning is now known as bbrowning_away
_djbkd has joined #jruby
skade has joined #jruby
lance|afk is now known as lanceball
pjammer has joined #jruby
pitr-ch has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
brauliobo has joined #jruby
cremes has quit [Ping timeout: 268 seconds]
rtyler has quit [Quit: leaving]
pitr-ch has joined #jruby
rtyler has joined #jruby
rtyler has quit [Client Quit]
cremes has joined #jruby
nateberkopec has joined #jruby
bbrowning_away is now known as bbrowning
rtyler has joined #jruby
rtyler has quit [Changing host]
rtyler has joined #jruby
drbobbeaty has quit [Read error: Connection reset by peer]
camlow32_ has quit [Remote host closed the connection]
drbobbeaty has joined #jruby
camlow325 has joined #jruby
havenwood has joined #jruby
<lopex>
enebo: \o/
<enebo>
lopex: NUMBERZ?
<lopex>
yes
jensnockert has joined #jruby
<enebo>
lopex: yeah I guess supporting this idiom is one less “education” thing we have to do now…although as an idiom people largely should not be using it
<lopex>
enebo: post rescue ?
<enebo>
lopex: yeah. over time you may decide to throw deeper in your stack (or someone else will decide too) and get hung up on a catchall
<enebo>
lopex: as a pattern it leads to confusion later
<enebo>
lopex: generally size and duration of support sort of implies how good/bad it is
<headius>
tarcieri: awesome
<enebo>
tarcieri: do people still use facets?
<enebo>
hmmm I guess he is still actively developing this
jensnock_ has joined #jruby
brauliobo has quit [Ping timeout: 240 seconds]
jensnockert has quit [Ping timeout: 260 seconds]
bb010g has joined #jruby
<tarcieri>
I have no idea
<nirvdrum>
enebo: So headius didn't come up with a way to break this?
<enebo>
nirvdrum: no?
yfeldblum has joined #jruby
<nirvdrum>
Okay. I just recall discussing something similar twice and I'm pretty sure he came up with a case that broke it each time.
<nirvdrum>
If not, great.
<nirvdrum>
Maybe it was 1.7.x specific.
<enebo>
nirvdrum: I think the crux of this opt is whether $! can possibly be seen / escape-from the rescue body
<enebo>
nirvdrum: so this is only for cases where the body of that escape cannot get a reference
<nirvdrum>
right.
subbu is now known as subbu|lunch
<GitHub112>
[jruby-openssl] mkristian pushed 1 new commit to master: http://git.io/vcWSw
<GitHub112>
jruby-openssl/master 3dbd038 Christian Meier: bump version [skip ci]
brauliobo has joined #jruby
brauliobo has quit [Ping timeout: 272 seconds]
pitr-ch has quit [Read error: No route to host]
pitr-ch has joined #jruby
yfeldblum has quit [Ping timeout: 246 seconds]
jensnock_ has quit []
tcrawley-away is now known as tcrawley
<xardion>
Is there a known issue with running jruby 9.0.1.0 on jdk 8u60?
subbu|lunch is now known as subbu
nateberkopec has quit [Read error: Connection reset by peer]
<xardion>
it's odd, everything runs fine with 8u40, but if I use the same jar with 8u60, it just silently fails to execute any ruby. Passing -help shows all the jruby usage opts though
havenn has joined #jruby
<xardion>
ahh nevermind. stupid RUBYOPT
havenwood has quit [Ping timeout: 256 seconds]
<GitHub102>
[jruby] eregon commented on commit c06ac7c: did you find out where it overflowed?... http://git.io/vclmJ
pawnbox has quit [Remote host closed the connection]
yfeldblum has joined #jruby
brauliobo has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
brauliobo has quit [Ping timeout: 272 seconds]
pjammer has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<nirvdrum>
enebo: Have any string benchmarks you particularly like?
<headius>
enebo: it seems like my "end rescue f" may not actually have worked...with your update to do rescue optz for full rescue form, bench looks like it's working right now
pjammer has joined #jruby
<headius>
with indy and no other flags, blocks jit and csv.rb parses 6.5MB of content with all converters on in 7.4s
elia_ has joined #jruby
<headius>
I should try yorick's bench again...that one needed blocks to jit too
tcrawley is now known as tcrawley-away
_djbkd has quit [Remote host closed the connection]
_djbkd has joined #jruby
tenderlo_ has quit [Quit: Leaving...]
<enebo>
nirvdrum: not entirely sure on any benches. A mixed bag
donV has joined #jruby
_djbkd has quit [Remote host closed the connection]
<donV>
chrisseaton: Hi! How are you doing?
<nirvdrum>
donV: chrisseaton is traveling a bit today. If he doesn't reply, he's not just being rude.
<headius>
enebo: ok I was wrong
<donV>
nirvdrum: :) thanks
<headius>
somehow by the time these blocks get to jit, Toggle is setting it to true
<headius>
if I run interpreted, they're false
_djbkd has joined #jruby
<headius>
simple case at command line jits and stays false
<donV>
nirvdrum: It would be good to have a stable address that contains the latest build.
<headius>
hmmm or not
<donV>
nirvdrum: I am checking 9.0.2.0 now
rsim has joined #jruby
<enebo>
headius: oh a pass kills it
<headius>
well it seems like something in my block jitting patch is breaking this, whether we jit or not
pjammer has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<headius>
confirming that now
<enebo>
headius: It seems perhaps isDeletable() is responsible
<enebo>
or not
<enebo>
it says it has a sideeffect
<enebo>
so it should not get removed by that
<headius>
I'm having trouble getting proper perf with stock csv.rb
<headius>
in any case
<enebo>
I am working on define_method again
<enebo>
Running into something bad
<enebo>
but this version is much more robust in theory
<donV>
nirvdrum: 9.0.2.0-SNAPSHOT contains the latest master
<enebo>
It will transmute IRClosure to IRMethod and fixup loading clousre instr + add in check_arity but it does it to startup IC so when full runs it will end up opting it like a nice method
<enebo>
So we should get that full 3x speedup we saw when I manually toggled ACP on
bb010g has quit [Quit: Connection closed for inactivity]
digitalextremist has quit [Ping timeout: 260 seconds]
<headius>
enebo: ugh
<headius>
these are setting true
<headius>
but I don't think they should
pjammer has joined #jruby
<enebo>
headius: the instr?
<enebo>
headius: it is static at IRBuild time
<headius>
they're true right away it seems
<enebo>
headius: they cannot be toggled after that point
<projectodd-ci>
tom.enebo: Use the singleton instances when loading from persistence and not constructing over and over
pjammer has joined #jruby
<headius>
nirvdrum: yeah I looked it over a bit
<nirvdrum>
It could be another optimization target.
<headius>
are fixes in for everything slowing truffle down there?
<nirvdrum>
donV: We missed the release window for whatever reason. We're just going to wait for truffle 0.9. That's what the truffle-head branch is targeting.
<headius>
last I was was just the block_given? issue
<nirvdrum>
headius: chrisseaton optimized block_given? and did some work on random. I'm not sure where he's at now.
<enebo>
last comment implied some more issues
<enebo>
but some interaction perhaps with benchmark/ips + the bench
<headius>
yeah, we were talking about block_given? optimization in normal JRuby...should be pretty easy
<nirvdrum>
I think he hit some issues with benchmark-ips.
<headius>
we can just reduce it to a single virtual call when it hasn't been overridden
<headius>
so it doesn't deopt surrounding method
<headius>
so we should speed up on that too, if it's hit hard
<headius>
fwiw, defined? yield is a fast form that does no dispatch
<headius>
little known Ruby hacks
<nirvdrum>
Heh.
<headius>
enebo: cremes bench looks pretty good but I may have a race condition in block jit
<headius>
similar to old race in method jit where it would step on executing code
<enebo>
ok. I will likely be leaving in a few for your house
<enebo>
going dark
enebo has quit [Quit: enebo]
samphippen has joined #jruby
dikaio has joined #jruby
<nirvdrum>
Does anyone know when RubyKaigi talks will be chosen?
samphippen has quit [Client Quit]
tenderlove has joined #jruby
bbrowning is now known as bbrowning_away
tenderlove has quit [Remote host closed the connection]
tenderlove has joined #jruby
<headius>
nirvdrum: unsure...I know they extended the CFP a bit
<headius>
cremes: good news...with all patches in place, your multi bench is definitely fastest on JRuby now
<headius>
with no hacky flags
<headius>
I have some threading fixes to make in the block jit before I land it