00:05
enebo has quit [Quit: enebo]
00:13
Aethenelle has joined #jruby
00:17
Aethenelle has quit [Ping timeout: 246 seconds]
00:23
rcvalle has quit [Quit: rcvalle]
00:40
tjohnson has joined #jruby
00:58
yfeldblum has quit [Ping timeout: 250 seconds]
01:19
skade has quit [Ping timeout: 272 seconds]
01:22
<
GitHub108 >
jruby/master 8454ab9 Kevin Menard: [Truffle] Removed the non-standard, obsoleted String `modify!` method.
01:22
<
GitHub108 >
jruby/master 8d93b27 Kevin Menard: [Truffle] Removed old, slow force_encoding.
01:25
yfeldblum has joined #jruby
01:40
johnsonch_afk is now known as johnsonch
01:57
nirvdrum has quit [Ping timeout: 240 seconds]
02:27
e_dub has quit [Read error: Connection reset by peer]
02:27
e_dub has joined #jruby
03:05
subbu|afk is now known as subbu
03:34
e_dub has quit [Read error: Connection reset by peer]
03:34
e_dub has joined #jruby
03:37
johnsonch is now known as johnsonch_afk
04:18
e_dub has quit [Read error: Connection reset by peer]
04:19
e_dub has joined #jruby
04:23
yfeldblum has quit [Read error: Connection reset by peer]
04:24
yfeldblum has joined #jruby
05:05
<
GitHub77 >
jruby/master e4fbb0b Subramanya Sastry: Init bitset size after the # of variables have been computed...
05:05
<
GitHub77 >
jruby/master cb5c911 Subramanya Sastry: Fix the order in which missing init instrs are added to entryBB...
05:06
thedarkone2 has quit [Quit: thedarkone2]
05:08
<
GitHub184 >
jruby/master 0972d79 Subramanya Sastry: Argh! Fix compilation error
05:08
pawnbox has joined #jruby
05:20
raeoks has joined #jruby
05:23
pawnbox has quit [Remote host closed the connection]
05:23
pawnbox has joined #jruby
05:30
pawnbox has quit [Remote host closed the connection]
05:30
pawnbox has joined #jruby
05:36
pawnbox has quit [Remote host closed the connection]
05:55
pawnbox has joined #jruby
06:07
pawnbox_ has joined #jruby
06:08
pawnbox has quit [Ping timeout: 260 seconds]
06:10
e_dub has quit [Read error: Connection reset by peer]
06:11
e_dub has joined #jruby
06:28
donV has joined #jruby
06:40
donV has quit [Read error: Connection reset by peer]
06:40
pawnbox has joined #jruby
06:43
pawnbox_ has quit [Ping timeout: 260 seconds]
06:45
donV has joined #jruby
06:50
donV has quit [Quit: donV]
07:01
donV has joined #jruby
07:04
donValentin has joined #jruby
07:04
donV has quit [Read error: No route to host]
07:09
rsim has joined #jruby
07:10
<
GitHub55 >
jruby-openssl/master dcf482c kares: avoid java.xx imports and maintain compatibility for JRuby 1.7
07:16
pawnbox has quit [Remote host closed the connection]
07:24
pawnbox has joined #jruby
07:31
prasunanand has joined #jruby
07:43
yfeldblum has quit [Ping timeout: 250 seconds]
07:43
pawnbox has quit [Remote host closed the connection]
07:51
skade has joined #jruby
07:55
<
GitHub10 >
jruby-openssl/master 144412f kares: [build] add (and test) a profile for JRuby 9.1.2.0
07:56
pawnbox has joined #jruby
07:59
<
GitHub150 >
jruby/test-jossl-0.9.17 2b58fac kares: let's test an upgrade to jruby-openssl 0.9.16
07:59
<
GitHub150 >
jruby/test-jossl-0.9.17 409109e kares: test out jruby-openssl 0.9.17 from staging
08:06
yfeldblum has joined #jruby
08:09
vtunka has joined #jruby
08:16
e_dub has quit [Read error: Connection reset by peer]
08:16
e_dub has joined #jruby
08:24
brauliobo_ has joined #jruby
08:24
brauliobo has quit [Ping timeout: 240 seconds]
08:28
pawnbox has quit [Remote host closed the connection]
08:35
rsim has quit [Ping timeout: 252 seconds]
08:38
pawnbox has joined #jruby
08:51
e_dub has quit [Read error: Connection reset by peer]
08:52
e_dub has joined #jruby
09:04
<
GitHub35 >
jruby/master b0fc315 Benoit Daloze: [Truffle] Fix compilation error in BodyTranslator....
09:04
e_dub has quit [Read error: Connection reset by peer]
09:05
e_dub has joined #jruby
09:05
<
GitHub178 >
jruby/master d2e65d0 Benoit Daloze: [Truffle] Inline modifyAndKeepCodeRange since it's just keepCodeRange now.
09:14
<
GitHub104 >
jruby/master c164be3 Benoit Daloze: [Truffle] Fix a few warnings and unused imports.
09:18
skade has joined #jruby
09:21
donValentin has quit [Quit: donValentin]
09:32
donV has joined #jruby
09:35
skade has quit [Quit: Computer has gone to sleep.]
09:39
yfeldblum has quit [Ping timeout: 250 seconds]
09:42
e_dub has quit [Read error: Connection reset by peer]
09:43
donV has quit [Quit: donV]
09:43
e_dub has joined #jruby
10:34
shellac has joined #jruby
10:40
pitr-ch has quit [Ping timeout: 240 seconds]
10:55
pitr-ch has joined #jruby
11:01
donV has joined #jruby
11:02
pitr-ch has quit [Ping timeout: 250 seconds]
11:04
pitr-ch has joined #jruby
11:46
donV has quit [Quit: donV]
11:55
prasunanand has quit [Ping timeout: 246 seconds]
11:59
tcrawley-away is now known as tcrawley
12:13
johnsonch_afk is now known as johnsonch
12:19
e_dub has quit [Read error: Connection reset by peer]
12:20
e_dub has joined #jruby
12:35
lance|afk is now known as lanceball
12:40
bbrowning_away is now known as bbrowning
12:41
skade has joined #jruby
13:34
pawnbox has quit [Remote host closed the connection]
13:36
pawnbox has joined #jruby
13:40
pawnbox has quit [Remote host closed the connection]
14:09
e_dub has quit [Read error: Connection reset by peer]
14:10
e_dub has joined #jruby
14:11
raeoks has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
14:17
skade has quit [Quit: Computer has gone to sleep.]
14:17
pawnbox has joined #jruby
14:25
pitr-ch has quit [Ping timeout: 240 seconds]
14:27
johnsonch is now known as johnsonch_afk
14:32
pitr-ch has joined #jruby
14:53
thedarkone2 has joined #jruby
14:57
<
GitHub110 >
jruby/master 4df0205 Chris Seaton: [Truffle] Fix units of allocation benchmark.
15:02
enebo has joined #jruby
15:02
<
GitHub160 >
jruby/master 6f670b6 Benoit Daloze: [Truffle] Extract areComparable() into its own node for String#==.
15:16
raeoks has joined #jruby
15:20
<
GitHub54 >
jruby/master bc82962 Benoit Daloze: [Truffle] Use CheckLayoutNode in String#==.
15:20
<
GitHub54 >
jruby/master c7e57bf Benoit Daloze: [Truffle] Remove usage of CheckLayoutNode where only used on slow path.
15:39
prasunanand has joined #jruby
15:43
hobodave has joined #jruby
15:45
yfeldblum has joined #jruby
15:47
subbu is now known as subbu|afk
15:51
subbu|afk is now known as subbu
15:58
kith has joined #jruby
16:16
vtunka has quit [Quit: Leaving]
16:18
<
GitHub151 >
jruby/master 1fdc645 Benoit Daloze: [Truffle] Replace transferToInterpreter to transferToInterpreterAndInvalidate....
16:24
e_dub has quit [Read error: Connection reset by peer]
16:25
e_dub has joined #jruby
16:26
adgtl has joined #jruby
16:26
bbrowning is now known as bbrowning_away
16:27
johnsonch_afk is now known as johnsonch
16:28
pawnbox has quit [Remote host closed the connection]
16:36
pawnbox has joined #jruby
16:41
yfeldblum has quit [Ping timeout: 250 seconds]
16:58
lanceball is now known as lance|afk
17:12
rcvalle has joined #jruby
17:23
shellac has quit [Quit: Leaving]
17:26
prasunanand has quit [Quit: Leaving]
17:31
yfeldblum has joined #jruby
17:49
e_dub has quit [Quit: It's a hard knock life]
17:52
e_dub has joined #jruby
17:57
yfeldblum has quit [Remote host closed the connection]
18:07
bbrowning_away is now known as bbrowning
18:10
lance|afk is now known as lanceball
18:20
<
headius >
kares_: have you done any fixing for jruby-openssl #94?
18:27
nirvdrum has joined #jruby
18:45
<
headius >
bbrowning: I'm looking at that x509 memory retention now
18:46
<
headius >
trying to find a cleaner way to deal with the security provider dance
18:47
<
GitHub43 >
jruby/master d8c74bf Chris Seaton: [Truffle] Run benchmarks post-push.
18:48
subbu is now known as subbu|lunch
18:48
<
GitHub194 >
jruby/truffle-head 221bd6c Chris Seaton: Merge branch 'master' into truffle-head
18:49
kith has quit [Quit: kith]
18:57
<
bbrowning >
headius: cool - thanks
18:58
<
headius >
bbrowning: hey I'm confused...I don't see it doing a simple require 'openssl'
18:58
<
bbrowning >
headius: it being what in this case?
18:58
<
headius >
or maybe visualvm is lying
18:59
<
bbrowning >
ahh the memory usage
18:59
<
headius >
well I see the cert array but they all seem pretty small
18:59
<
headius >
retained heap wise
18:59
<
headius >
and total heap use is only 22MB
18:59
<
headius >
yeah maybe
18:59
<
headius >
I'll try that
18:59
<
bbrowning >
or let bundler via a https gem source
19:02
<
headius >
opening http doesn't seem to do it
19:02
<
headius >
and it does appear that loading openssl should be sufficient
19:02
<
headius >
that boots x509 which boots x509cert
19:02
<
bbrowning >
and you're using a version of jruby-openssl that pulls in bouncycastle 1.5.4?
19:03
<
headius >
well I'm using master
19:06
<
headius >
sorry, it boots X509Store, which does the cert walking
19:06
<
headius >
X509Store.createX509Store(runtime, _X509);
19:06
<
headius >
oh wait, maybe it doesn't
19:13
<
kares_ >
headius: not really - have an idea of porting the X509 factory over and using it from SecurityHelper but it seems like a hustle
19:14
<
headius >
kares_: what triggers these certs to load?
19:14
<
kares_ >
headius: bbrowning: fixed the jruby.openssl.provider.register=true which will do as a work-around
19:14
<
headius >
I want to try a few things but I need to reproduce
19:14
<
headius >
yeah I saw that, that's the first thing I wanted to confirm
19:14
<
kares_ >
headius: did not reproduce myself
19:15
rueben_ has joined #jruby
19:15
<
kares_ >
some cert matching code linked from the GH issue
19:16
<
bbrowning >
headius: on my machine, the certs all get loaded when bundler does its thing
19:16
<
bbrowning >
I'm sure there are other ways as well, but that's the obvious one for me
19:17
<
headius >
ok, I'll try that angle
19:17
<
kares_ >
also some httpclient fetching should do
19:17
<
kares_ >
(same cause as #94)
19:17
<
headius >
oh thanks
19:17
<
GitHub15 >
jruby/master f30009c Thomas E. Enebo: Dynamic constructs were never using frozen strings for StrNodes....
19:18
<
headius >
kares_: we still have code to register/unregister a provider around some call, right?
19:18
<
headius >
we could use that in the short term to register the provider temporarily while getting cert factory
19:18
<
kares_ >
headius: off by default and the on property I mentioned above wasnt working
19:18
<
kares_ >
now it is - which should do as a work-around
19:18
<
kares_ >
was also eager for a new jossl release due this ...
19:19
<
headius >
I'll ask reporter of jruby #3941 to try that property
19:19
<
kares_ >
headius: won't work until jossl 0.9.17
19:19
<
kares_ >
... which I am testing with jruby currently (not released yet - maybe tomorrow or next week)
19:20
<
kares_ >
headius: should I hold off a jossl release for you if jruby is green?
19:21
<
headius >
kares_: if it's green there's no reason not to release
19:21
<
headius >
but it just has a workaround for this right? It isn't actually fixing it or on by default?
19:21
<
kares_ >
ok - sure won't do it in the next 12 hours or so
19:22
<
kares_ >
headius: the thing with turning the property on is that it leaks than
19:22
<
headius >
because it never unregisters the provider
19:22
<
kares_ >
BC is loaded by jruby so setting up a provider with JRuby's CL leaks
19:22
<
headius >
that's why we had the code to register/unregister around some operation
19:23
<
headius >
a better option would be to register it but add a hook to JRubyClassLoader's teardown to unregister it
19:23
<
kares_ >
that unregistering was a bit crazy - I know it existed but didn't work properly when I got involved
19:23
<
kares_ >
headius: yes that sounds better
19:24
<
headius >
we do that for jdbc already
19:24
<
headius >
incredible to me those two registration mechanisms have never been fixed in JDK
19:24
<
kares_ >
yes I know I am not sure how much its needed
19:24
<
kares_ >
it probably is - some drivers deal with it already
19:25
<
kares_ >
... but some dont unregister
19:25
<
bbrowning >
try/finally with register/unregister
19:26
<
headius >
bbrowning: ahh that's not a bad hack either
19:26
<
headius >
as a short term fix we could do that
19:26
<
headius >
kares_: what do you think of that
19:27
<
kares_ >
:) a HACK ... but I am not against it
19:27
<
bbrowning >
although...
19:27
<
headius >
I still can't reproduce it
19:27
<
kares_ >
its better than nothing
19:27
<
bbrowning >
I just tried to clean up that code a bit but haven't tested it - I may have the wrong contents inside the try/finally block
19:27
<
bbrowning >
the leaking bits may be the return value of this method - the hack I was using before had this somewhere else
19:28
<
headius >
it looks ok to me
19:28
<
bbrowning >
let me try to reproduce as well
19:28
<
bbrowning >
so we can verify the fix easily
19:28
<
headius >
the provider we pass in here should have been constructed once and cached
19:28
<
kares_ >
bbrowning: are you sure it worked? I mean is its only checking when the X509 factory is constructed to have the BC provider registered
19:28
<
kares_ >
... and it won't miss it afterwards
19:29
<
headius >
kares_: if I understand right, it's the factory construction that causes a new provider to be created, right?
19:29
<
bbrowning >
headius: the provider you pass in here may be cached but that provider is different than the provider BC constructs internally if BC isn't registered
19:29
<
kares_ >
headius: that is what I ws asking bbrowning :)
19:29
<
headius >
bbrowning: different?
19:29
<
bbrowning >
kares_: I was sure my previous hack worked but it used to have the entire contents of this getCertificateFactory inside a try/finally w/ register/unregister
19:29
<
headius >
a different class altogether or just a different instance?
19:30
<
bbrowning >
headius: yessir, different - BC internally creates its own instance of the provider
19:30
<
kares_ >
bbrowning: ok - thanks
19:30
<
headius >
ok just its own instance
19:30
<
kares_ >
than I have no objections for having it in
19:30
<
headius >
because nothing is registered
19:30
<
headius >
this seems fine
19:30
<
headius >
I thought there was a utility method for register/unregister that would be better to use
19:30
prasunanand has joined #jruby
19:31
<
bbrowning >
kares_: the diff I posted should fix this leak, but I'd like to verify w/ a simple reproducer
19:31
<
headius >
it's pretty annoying that when we create the certificate SPI
*with the proper provider* that it doesn't use that provider
19:31
<
kares_ >
headius: that code was likely deleted by me as for a while BC registration wasn't needed at all
19:31
<
headius >
kares_: ah ok
19:32
<
bbrowning >
headius: well, the thing is final CertificateFactorySpi spi = (CertificateFactorySpi) getImplEngine("CertificateFactory", type);
19:32
<
headius >
the boot sequence for jossl needs some serious cleanup I gues
19:32
<
kares_ >
did a full BC review and ported over some code where it needed a provider
19:32
<
kares_ >
this is some new shit from BC 1.54 ;(
19:32
<
bbrowning >
it's when this CertificateFactorySpi gets created that BC creates a new Provider
19:32
<
headius >
bbrowning: oh it's getting the SPI itself that triggers the provider reigstration?
19:33
<
bbrowning >
perhaps something BC could/should fix upstream? I dunno anything about why they made this change
19:33
rueben_ has quit [Quit: Ex-Chat]
19:33
<
headius >
yeah me neither
19:33
rueben_ has joined #jruby
19:34
<
headius >
I'm going to file an issue for them
19:35
<
kares_ >
not sure they will do anything ... its a pretty valid assumption that BC to be registered if you use the java.security API that does end up using their impls
19:36
<
kares_ >
... were the ones playing dirty ... but do not mention that :)
19:40
<
headius >
well, hopefully they know how shitty the registration stuff is too
19:40
<
headius >
I'm just saying that we have mostly tried to use BC without registering it, and up to now that has worked ok
19:41
<
headius >
so let's go with bbrowning's patch once we can reproduce, and we'll see what the BC folks have to say
19:42
rueben_ has quit [Quit: Ex-Chat]
19:43
rueben_ has joined #jruby
19:47
rueben_ has quit [Read error: Connection reset by peer]
19:48
subbu|lunch is now known as subbu
19:48
rueben_ has joined #jruby
19:48
<
headius >
bbrowning: you can reproduce this with TB I assume...are you verifying the patch?
19:49
<
headius >
I have tried open-uri and httpclient and can't get the certs to load
19:54
<
bbrowning >
basically just a simple script to activate the correct jruby-openssl gem and then do a bundle install on a basic Gemfile with a https source
19:55
<
bbrowning >
without my patch is OOMs, with my patch it doesn't
19:55
<
bbrowning >
-Xmx80m is just a fudge number I guessed based on knowing 65MB of bouncycastle stuff gets loaded on my machine when it's misbehaving
19:55
<
headius >
let's go with it then
19:56
<
headius >
I'll try to come up with a test that confirms all certs we cache have the same provider
20:00
rueben_ has quit [Quit: Ex-Chat]
20:00
rueben_ has joined #jruby
20:02
<
bbrowning >
headius: I can confirm this patch fixes TB4 integration tests as well. Without the patch, we OOM with the default 512MB heap. With the patch everything's fine.
20:03
<
bbrowning >
the problem is exaggerated there because we create multiple runtimes in our integs triggering lots of BC memory usage
20:05
<
bbrowning >
that failed before and passes now?
20:05
<
headius >
oops, assertEquals
20:05
<
headius >
I'm testing that now
20:06
<
headius >
it doesn't fail
20:06
<
headius >
but maybe the tests register BC?
20:07
<
GitHub44 >
jruby/master 1d0b00a Thomas E. Enebo: Array literals can add String Literals out of order
20:08
<
bbrowning >
perhaps so
20:09
<
headius >
I'll figure it out
20:09
<
headius >
bbrowning: thanks for confirming with TB
20:09
<
headius >
I'll get patch and test in today
20:10
<
bbrowning >
welcome!
20:16
donV has joined #jruby
20:23
<
headius >
damn, still doesn't fail
20:24
<
headius >
even unregistering all existing providers first (only one)
20:24
<
headius >
donV: hi!
20:38
<
kares_ >
headius: go for assertSame ... Provider instances act as a Map so they likely have equals
20:50
bbrowning is now known as bbrowning_away
20:54
<
headius >
kares_: still the same :-\
20:54
<
headius >
I'm missing something
20:55
prasunanand has quit [Read error: Connection reset by peer]
20:58
prasunanand has joined #jruby
20:59
pawnbox has quit [Remote host closed the connection]
21:05
tcrawley is now known as tcrawley-away
21:09
<
GitHub48 >
jruby/master a1047ee Thomas E. Enebo: All StrNodes encountered need not worry about order and can get...
21:12
hobodave has quit [Ping timeout: 246 seconds]
21:20
<
headius >
well I'm stumped
21:20
<
headius >
oh wait...wtf...it's not using BC
21:21
<
headius >
so why doesn't it do that in bbrowning's case
21:21
<
kares_ >
headius: aaah
21:22
<
kares_ >
so you should just get the BC jars on CP
21:22
<
headius >
maybe getCertificateFactory is actually erroring and falling back on CertificateFactory.newInstance
21:22
<
kares_ >
yes that should be it
21:22
<
headius >
blah, that was it...silent fail
21:22
<
headius >
so maybe it can't find BC
21:22
<
headius >
oh actually I'm wrong
21:22
<
headius >
it doesn't error
21:22
<
headius >
it errors for another test that's supposed to error
21:22
<
kares_ >
require 'openssl' does load the .jar
21:23
<
kares_ >
the .java part does not?
21:23
<
headius >
that could be
21:23
<
kares_ >
I mean the java test-case
21:23
<
headius >
we don't have a lot of java test cases in here
21:23
<
kares_ >
yes really just unit tests
21:23
<
kares_ >
mostly tested in ruby
21:23
<
headius >
any they don't appear to try to load bc
21:24
<
kares_ >
likely wasn't needed for 'simple' unit tests testin isolated java parts
21:28
<
headius >
kares_: are the tests under src/test/ruby ones we've written?
21:31
<
headius >
it passes in a Ruby test too
21:38
<
headius >
bbrowning_away: you're on linux right? I wonder if the cert logic that fires on OS X doesn't fall down this path
21:38
<
headius >
the other reporter was on Linux too
21:39
<
headius >
kares_: can you try my tests and see if they fail for you on Linux?
21:39
<
headius >
oh heh I guess I can just push to travis too and see what happens
21:40
<
GitHub140 >
jruby-openssl/master 13e964a Charles Oliver Nutter: Add a test for #94...should fail on Travis.
21:41
<
headius >
kares_: we should reduce the number of versions we test against too, probably to latest 1.6, 1.7, and 9k
21:41
<
headius >
would speed up CI
21:50
lanceball is now known as lance|afk
21:51
<
headius >
damn, it passed on travis too
21:51
johnsonch is now known as johnsonch_afk
21:51
<
headius >
I may not be able to come up with a test for this that doesn't involve a more complex setup
21:52
<
kares_ >
yes its probably fine to reduce - some of its verbosity (e.g. 1.7) is due incompatibilities being added over time
21:53
<
kares_ >
I am off to sleep - will review things as they are tomorrow
21:53
<
headius >
kares_: ok
21:53
<
headius >
goodnight
21:53
rueben_ has quit [Ping timeout: 240 seconds]
21:57
<
GitHub149 >
jruby-openssl/master ea229e0 Charles Oliver Nutter: Add @bbrowning fix for #94....
22:07
pitr-ch has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
22:11
subbu is now known as subbu|away
22:26
<
GitHub139 >
jruby/master 4071392 Chris Seaton: [Truffle] Fix visibility to respond_to? when at the top level and in the first required file.
22:26
<
GitHub139 >
jruby/master cba8d93 Chris Seaton: [Truffle] Get rid of Ruby methods as Rubinius primitives.
22:26
<
GitHub139 >
jruby/master fa866cf Chris Seaton: [Truffle] Load all core files directly, rather than requiring in core.rb
22:47
donV has quit [Quit: donV]
22:50
enebo has quit [Quit: enebo]
22:57
e_dub has quit [Quit: ZZZzzz…]
22:58
skade has joined #jruby
23:10
yfeldblum has joined #jruby
23:15
<
headius >
huh, graal runs our interpreter faster
23:16
<
chrisseaton >
well that's the idea - it doesn't run with indy faster as we haven't optimised for that
23:16
<
chrisseaton >
does it run compiled but no indy slow though? that's the weird one
23:19
skade has quit [Quit: Computer has gone to sleep.]
23:25
<
headius >
red/black with indy looks about the same on graal versus hotspot
23:25
<
headius >
I'll try no-indy in a sec
23:25
<
chrisseaton >
that's allocation bound though isn't it?
23:26
<
headius >
well, indy is 3-4x faster than non-indy on hotspot
23:26
<
headius >
and truffle is about 2x faster than jruby with indy
23:28
<
headius >
2-3x I guess...0.4xx versus 0.15x
23:30
<
headius >
chrisseaton: graal + jruby jit with no indy on red/black is still a bit slower than hotspot
23:30
<
headius >
1.5-1.6s per iter compared to 1.4s
23:32
<
headius >
about the same on fib
23:38
<
headius >
not sure if you've been publishing them somewhere regularly
23:41
<
chrisseaton >
I've written a new benchmarking system, designed to let us see things like warmup and cyclic behaviour better
23:42
<
chrisseaton >
So there'll be new results from that soon
23:42
<
chrisseaton >
I've also written an interface that lets you run any benchmark system (like bips, rbench) with any other benchmark runner
23:42
<
chrisseaton >
This is so we can run the MRI benchmarks for example
23:42
<
chrisseaton >
And you can run our benchmarks with bips locally, for much less hassle
23:44
<
headius >
yeah I saw that work
23:44
<
headius >
ok...I'd like to try tracking standard jruby's perf over the last few releases, make sure we're progressing
23:48
<
headius >
and as we go forward with more ambitious IR stuff, of course
23:50
<
chrisseaton >
We run indy benchmarks nightly, and soon we'll run non indy as well
23:50
<
chrisseaton >
Might add interrpeter
23:50
<
headius >
great, thank you
23:50
<
headius >
I want to start looking at more shape specialization too
23:50
<
headius >
working locally on small arrays without the extra boxing
23:51
<
chrisseaton >
I haven't seen any regressions yet - I wasn't going to bother you with steady increases, and here have been a few (richards, red-black)
23:51
<
chrisseaton >
Of course it's hard to tell when you're squashed at the bottom of the same graph as us :)
23:51
<
headius >
that's good to hear
23:52
<
chrisseaton >
Our new system will let me get reports on just you, and I can share those every now and again
23:56
rueben has joined #jruby
23:56
<
headius >
chrisseaton: hey, is your object shaping just implemented as part of jruby+truffle or does truffle provide something here?
23:57
<
headius >
I have not had a close look at it
23:57
<
chrisseaton >
it's all truffle
23:57
<
headius >
where in truffle is that located?
23:58
<
chrisseaton >
com.oracle.truffle.api.object
23:58
<
chrisseaton >
eg DynamicObject
23:58
<
headius >
does that really need your language to be implemented in truffle?
23:58
<
headius >
seems like it should be possible to specialize objects for plain JVM use too
23:58
<
chrisseaton >
I don't think it absolutely needs it
23:58
<
chrisseaton >
You have to do your own work in truffle to cache a name to a location
23:59
<
chrisseaton >
So if you did that using indy instead, it should be ok
23:59
<
chrisseaton >
Then the location abstraction should be inlineable by HotSpot I think
23:59
<
chrisseaton >
Look at ReadObjectFieldNode