ITXpander has quit [Client Quit]
camlow32_ has quit [Remote host closed the connection]
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 244 seconds]
TheWhip has joined #jruby
TheWhip has quit [Ping timeout: 260 seconds]
johnsonch is now known as johnsonch_afk
<GitHub159> [jruby] ranjithdharmaraj opened issue #4050: SMTP IOError: Network is unreachable on windows https://git.io/v6mEE
djellemah has quit [Ping timeout: 240 seconds]
e_dub has quit [Quit: ZZZzzz…]
e_dub has joined #jruby
e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
pawnbox has joined #jruby
TheWhip has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
yfeldblum has quit [Remote host closed the connection]
TheWhip has quit [Remote host closed the connection]
e_dub has quit [Quit: ZZZzzz…]
pawnbox has quit [Ping timeout: 276 seconds]
pawnbox has joined #jruby
djellemah has joined #jruby
<GitHub56> [jruby] bjfish pushed 1 new commit to master: https://git.io/v6mw9
<GitHub56> jruby/master 064d29c Brandon Fish: [Truffle] Implement File.mkfifo
camlow325 has joined #jruby
TheWhip has joined #jruby
<GitHub75> [jruby] bjfish pushed 1 new commit to master: https://git.io/v6mrR
<GitHub75> jruby/master 67965d5 Brandon Fish: [Truffle] File.mkfifo fix/style
<GitHub58> [jruby] bjfish pushed 1 new commit to master: https://git.io/v6mr0
<GitHub58> jruby/master aeeabf8 Brandon Fish: [Truffle] Untag passing File errno specs
yfeldblum has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
<GitHub54> [jruby] bjfish pushed 1 new commit to master: https://git.io/v6moo
<GitHub54> jruby/master 86cb695 Brandon Fish: [Truffle] Kernel#` to coerce command using #to_str
thedarkone2 has quit [Quit: thedarkone2]
<travis-ci> jruby/jruby (master:67965d5 by Brandon Fish): The build has errored. (https://travis-ci.org/jruby/jruby/builds/149954185)
raeoks has joined #jruby
raeoks has quit [Quit: Textual IRC Client: www.textualapp.com]
yfeldblum has quit [Ping timeout: 250 seconds]
jimbaker has quit [Ping timeout: 250 seconds]
jimbaker has joined #jruby
jimbaker has quit [Changing host]
jimbaker has joined #jruby
<travis-ci> jruby/jruby (master:aeeabf8 by Brandon Fish): The build has errored. (https://travis-ci.org/jruby/jruby/builds/149954300)
yfeldblum has joined #jruby
TheWhip_ has joined #jruby
raeoks has joined #jruby
pil-afk is now known as pilhuhn
TheWhip has quit [Ping timeout: 252 seconds]
pawnbox has quit [Ping timeout: 276 seconds]
pawnbox has joined #jruby
camlow325 has quit [Remote host closed the connection]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
rsim has joined #jruby
rsim has quit [Client Quit]
jimbaker has quit [Ping timeout: 258 seconds]
ITXpander has joined #jruby
jimbaker has joined #jruby
jimbaker has quit [Changing host]
jimbaker has joined #jruby
ITXpander has quit [Client Quit]
claudiuinberlin has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
<GitHub99> [jruby] kares pushed 1 new commit to master: https://git.io/v6myl
<GitHub99> jruby/master 58a5a81 kares: Enumerator is top level constant these days + final-ize ALLOCATOR
pawnbox has quit [Read error: Connection reset by peer]
pawnbox has joined #jruby
skade has joined #jruby
pawnbox has quit [Read error: Connection reset by peer]
skade has quit [Ping timeout: 252 seconds]
<travis-ci> kares/jruby (ji-enumerator:8d5f7b4 by kares): The build has errored. (https://travis-ci.org/kares/jruby/builds/149973093)
yfeldblum has quit [Ping timeout: 250 seconds]
TheWhip_ has quit [Remote host closed the connection]
<travis-ci> kares/jruby (ji-enumerator:8d5f7b4 by kares): The build has errored. (https://travis-ci.org/kares/jruby/builds/149973093)
pawnbox has joined #jruby
TheWhip has joined #jruby
TheWhip has quit [Ping timeout: 258 seconds]
TheWhip has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
<GitHub133> [jruby] eregon pushed 7 new commits to master: https://git.io/v6m7g
<GitHub133> jruby/master 7ba8959 Benoit Daloze: [Truffle] JT: Make sure bin/ruby points to the right launcher.
<GitHub133> jruby/master e5cf5a8 Benoit Daloze: [Truffle] JT: Run the metrics using the capture mechanism so errors are properly printed.
<GitHub133> jruby/master bb8f30b Benoit Daloze: [Truffle] jruby_mx: support -J and classpath.
skade has joined #jruby
pawnbox has quit [Ping timeout: 250 seconds]
skade has quit [Ping timeout: 244 seconds]
<GitHub45> [jruby] eregon pushed 1 new commit to truffle-head: https://git.io/v6mdf
<GitHub45> jruby/truffle-head 9be0bad Benoit Daloze: Merge remote-tracking branch 'origin/master' into truffle-head
pawnbox has joined #jruby
<travis-ci> kares/jruby (test-ji-enumerator:2752cbd by kares): The build passed. (https://travis-ci.org/kares/jruby/builds/149982034)
vtunka has joined #jruby
skade has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
skade has quit [Ping timeout: 276 seconds]
<GitHub15> [jruby] eregon pushed 1 new commit to master: https://git.io/v6mjk
<GitHub15> jruby/master 5585439 Benoit Daloze: [Truffle] JT: Times metrics are printed on stderr and memory metrics on both streams.
e_dub has joined #jruby
TheWhip has quit [Remote host closed the connection]
ale_ has quit [Ping timeout: 264 seconds]
ale has joined #jruby
vtunka has quit [Quit: Leaving]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
TheWhip has joined #jruby
vtunka has joined #jruby
vtunka_ has joined #jruby
vtunka_ has quit [Client Quit]
<GitHub84> [jruby] eregon pushed 1 new commit to truffle-head: https://git.io/v6YJr
<GitHub84> jruby/truffle-head 2bfe445 Benoit Daloze: Merge remote-tracking branch 'origin/master' into truffle-head
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
skade has joined #jruby
bbrowning has joined #jruby
skade has quit [Read error: Connection reset by peer]
skade has joined #jruby
tcrawley-away is now known as tcrawley
raeoks has quit [Quit: Textual IRC Client: www.textualapp.com]
ITXpander has joined #jruby
TheWhip has quit [Remote host closed the connection]
<kegster> Can I just have 'begin' then code, then 'rescue' then code to run if it fails? without having 'rescue foo=>bar' ?
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 252 seconds]
<yopp> um
<yopp> I'm having real trouble with SecureRandom on 9.1.2.0. SecureRandom.hex(16) takes like 160 seconds
<yopp> I'm out of entropy?
<yopp> yeah
Tristitia has quit [Remote host closed the connection]
pawnbox has joined #jruby
zacts has joined #jruby
Tristit1a has joined #jruby
pawnbox has quit [Ping timeout: 250 seconds]
<yopp> holy fuck. that's why our CI took like 20 min
tcrawley is now known as tcrawley-away
tcrawley-away is now known as tcrawley
Tristit1a is now known as Tristitia
bbrowning is now known as bbrowning_away
<GitHub37> [jruby] bjfish pushed 1 new commit to master: https://git.io/v6Y4O
<GitHub37> jruby/master decc1a3 Brandon Fish: [Truffle] Update File.mkfifo arg handling
zacts has quit [Quit: WeeChat 1.4]
zacts has joined #jruby
<GitHub31> [jruby] eregon pushed 2 new commits to master: https://git.io/v6Y0U
<GitHub31> jruby/master 1890c06 Benoit Daloze: [Truffle] Fix error message in CheckArityNode when there are optional arguments.
<GitHub31> jruby/master a44b822 Benoit Daloze: [Truffle] Keep it simple and idiomatic in File#mkfifo.
vtunka has quit [Quit: Leaving]
thedarkone2 has joined #jruby
camlow325 has joined #jruby
<GitHub78> [jruby] eregon pushed 1 new commit to master: https://git.io/v6Yul
<GitHub78> jruby/master 3d7d59e Benoit Daloze: [Truffle] Trying to untag a few spawn specs.
ITXpander has quit [Quit: Leaving.]
<GitHub72> [jruby] eregon pushed 1 new commit to master: https://git.io/v6Yru
<GitHub72> jruby/master 4a06018 Benoit Daloze: [Truffle] Implement full Process.kill.
pilhuhn is now known as pil-afk
cprice404 has quit [Quit: Konversation terminated!]
zacts has quit [Quit: WeeChat 1.4]
jimbaker has quit [Ping timeout: 276 seconds]
jimbaker has joined #jruby
jimbaker has quit [Changing host]
jimbaker has joined #jruby
mberg has quit [Ping timeout: 250 seconds]
thedarkone2 has quit [Quit: thedarkone2]
skade has quit [Quit: Computer has gone to sleep.]
zacts has joined #jruby
bbrowning_away is now known as bbrowning
claudiuinberlin has quit []
cprice404 has joined #jruby
<GitHub196> [jruby] eregon pushed 4 new commits to master: https://git.io/v6YQO
<GitHub196> jruby/master 301c6fe Benoit Daloze: [Truffle] posix_spawnp(3) returns an int not a long.
<GitHub196> jruby/master d76fa47 Benoit Daloze: Use a fixture rather than inline code which needs lots of escape characters
<GitHub196> jruby/master f415ec0 Benoit Daloze: [Truffle] Fix a few bugs and missing methods around #spawn.
mberg_ has joined #jruby
enebo has joined #jruby
mberg_ is now known as mberg
Tristitia has quit [Ping timeout: 260 seconds]
<travis-ci> jruby/jruby (master:3d7d59e by Benoit Daloze): The build was broken. (https://travis-ci.org/jruby/jruby/builds/150076709)
Tristitia has joined #jruby
<GitHub58> [jruby] chrisseaton pushed 1 new commit to master: https://git.io/v6YFM
<GitHub58> jruby/master d1b6d5e Chris Seaton: [Truffle] Update LabsJDK.
<GitHub160> [jruby] chrisseaton pushed 2 new commits to truffle-head: https://git.io/v6YbC
<GitHub160> jruby/truffle-head 13c55e2 Chris Seaton: Merge branch 'master' into truffle-head
<GitHub160> jruby/truffle-head 01540ce Chris Seaton: [Truffle] Update LabsJDK.
thedarkone2 has joined #jruby
skade has joined #jruby
Tristitia has quit [Ping timeout: 244 seconds]
Tristitia has joined #jruby
claudiuinberlin has joined #jruby
subbu is now known as subbu|lunch
<bascule> _____ ____ ___ ____ _ __ ___ _ _
<bascule> | ___| _ \|_ _| _ \ / \\ \ / / | | |
<bascule> | |_ | |_) || || | | |/ _ \\ V /| | | |
<bascule> | _| | _ < | || |_| / ___ \| | |_|_|_|
<bascule> |_| |_| \_\___|____/_/ \_\_| (_|_|_)
<bascule>
<enebo> YES!
zacts has quit [Ping timeout: 244 seconds]
subbu|lunch is now known as subbu
tcrawley is now known as tcrawley-away
<headius> yopp: I wonder how many people this is affecting
<headius> it may be the reason for stupid 30 minute app startup times we've heard about
<headius> enebo: fix it
* headius has spoken
<yopp> !
<enebo> hahaah fix what?
<yopp> I think it's worth to try to add at least some kind of timeout
<yopp> entropy!
<headius> enebo: the way we're doing SecureRandom seems to still be really sensitive to burning out entropy
<enebo> oh still entropy exhaustian
<enebo> heh spelling genius
<headius> this probably never affects us because we don't dev on linux
<enebo> it uses same underlying source as MRI?
<headius> oh no
<headius> we have our own
<headius> we had a thread a year back or so trying to figure out how to have faster SecureRandom without compromising security
<enebo> I do remember tony and a few others discussing this a couple of years ago
<headius> I guess we didn't go far enough
<headius> there's a couple active bugs in tracker related to this
<headius> realjenius voted for us to revisit it and others said they're still seeing problems
<headius> installing an entropy-maker works but nobody knows to do that
<enebo> so MRI is not so random and ours is better but we burn out entropy too quickly and slow to a crawl
<headius> I think so
<enebo> hmm
<yopp> Our entropy graph is pretty jigsaw-ish
<headius> I remember looking into what MRI does and being a bit confused...I think they might use OpenSSL's PRNG but it also looked like that has a fallback
<headius> yopp: you can see that?
<yopp> yeah
<enebo> HAHAH
<headius> wowiw
<headius> what tool is that?
<yopp> prometheus + node_exporter + grafana
<headius> yeah we're eating the heck out of it
<enebo> STOP THE WORLD WE NEED MORE ENTROPY
<headius> hahah
<yopp> I'm not sure it's jruby
<headius> yopp: well I'm sure we're not helping
<yopp> that's for sure :)
<enebo> can OSes make a larger pool
<headius> ugh...I have to dig all these details out of the dusty closet of my mind
jimbaker has quit [Ping timeout: 265 seconds]
<yopp> enebo, we fixed that by simply starting havenged docker image on all hosts
<enebo> I do not think it is nice to fully punt but I am wondering if a pool reaches a vcertain size if the pool stops being a sawtooth
<yopp> and now our CI is like 3x faster
<yopp> In our case it reached zero
<yopp> now havenged provides more entropy is it goes below 1k
<enebo> yeah but does entropy typically just run until it is gone and rebuild some…there is none trickling in somehow?
<headius> yeah I don't know
<enebo> I feel like I am just leeching knowledge here but this is one topic I have never read up on
<yopp> it rebuilds very slowly. and since /dev/random is blocking until it can get requested bits
<enebo> WTF tarcieri where are you? :)
<enebo> sure he is here to be fancy on friday's
<enebo> fridays
<yopp> so in our case SecureRandom.hex(16) in sprockets blocked app for 3 minutes
<enebo> ouch
<headius> hmmm
<enebo> cheald I think had some solution to this prioblem with an external thing
jimbaker has joined #jruby
<headius> I wonder if it's failing to use the SHA1PRNG
<headius> yopp: what JDK version?
<enebo> I just saw him mention something about that but I not know what it is
jimbaker has quit [Changing host]
jimbaker has joined #jruby
<enebo> 1.3.2
<headius> so I try to force the SHA1PRNG because it just grabs entropy at boot and is pseudo-random from there on
<headius> secureRandom = SecureRandom.getInstance("SHA1PRNG");
<headius> enebo: yeah he used an entropy-maker too
<headius> that seems to work around it well
<headius> but it's not a solution
<yopp> java version "1.8.0_92"
<yopp> Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
<yopp> on alpine
<yopp> in docker
<yopp> orchestraged by rancher
<yopp> and the whole thing is running on openstack :D
<headius> yopp: can you try to run this in JRuby please: java.security.SecureRandom.getInstance("SHA1PRNG")
<yopp> => #<Java::JavaSecurity::SecureRandom:0x703580bf>
<headius> hmm, we do this for every ThreadContext...so I suppose spinning a ton of threads or fibers could burn up a lot of entropy
<headius> I just wouldn't expect that to spin fast enough
<headius> we moved to thread-local SecureRandom to avoid contention
<headius> yopp: ok
<headius> so it did work
<headius> damn
<yopp> SHA1 prng doesn't sounds good
<headius> we did a randomness test and it was as good as going to urandom all the time
<headius> but it isn't supposed to eat up entropy
<GitHub21> [jruby] enebo pushed 3 new commits to master: https://git.io/v6OLf
<GitHub21> jruby/master a24633e Thomas E. Enebo: Remove IPC from Instr. Not really used beyond inlining and our inlining...
<GitHub21> jruby/master 4175f39 Thomas E. Enebo: Remove RPC from instr. Remove unused interpreter engines (at least for...
<GitHub21> jruby/master 50882dc Thomas E. Enebo: Merge branch 'master' into mutate
<yopp> headius, I think there should be two sources of randomness
<yopp> but I'm not infosec expert, but I don't like the idea when something is happens behind the scene, that can affect security
<enebo> what the hell
<enebo> it shows a merge conflict locallt
<yopp> but also I'm not sure about using SecureRandom for example, for key generation
<enebo> it was a clean merge before I merged
<headius> jruby -e 'Java::sun.security.jca.Providers.getProviderList.providers.each {|p| p.services.each {|s| puts s.algorithm if s.type == "SecureRandom" } }'
<headius> I get four items for that
<enebo> ah ok somehow I have a .rej file from earlier :)
<headius> NativePRNG, SHA1PRNG, NativePRNGBlocking, NativePRNGNonBlocking
<yopp> headius, same
<headius> those last two presumably are /dev/random and /dev/urandom
<headius> yopp: can you build JRuby?
<yopp> not at the moment :(
<headius> ok
<headius> enebo: I'm going to make the PRNG we request a property for the moment, so at least it can be altered without a rebuild
<enebo> headius: makes sense to me
<enebo> headius: as a classname right?
<headius> provider/service name
<headius> so those names above
<yopp> A cryptographically strong random number minimally complies with the statistical random number generator tests specified in FIPS 140-2
<yopp> from the java docs on SecureRandom
<yopp> FIPS sounds serious!
<yopp> For all other hash function applications, the use of SHA-1 is acceptable. The
<yopp> other applications include HMAC, Key Derivation Functions (KDFs), Random Number
<yopp> Generation (RNGs and RBGs), and hash-only applications (e.g., hashing passwords
<yopp> and using SHA-1 to compute a checksum, such as the approved integrity technique
<yopp> specified in Section 4.6.1 of [FIPS 140-2]).
<yopp> oppsie
<yopp> but anyways, seems like SHA1PRNG is acceptable solution
<yopp> SHA1 deprecated only for signature generation
<headius> yopp: yeah we used one of those tests
<headius> but it's still slurping down too much entropy
<headius> well, something is
<headius> I guess we don't know it's JRuby
<headius> but we are sensitive to it
<yopp> Seems like JVM in general is sensitive to it
<headius> yopp: I will push this config property to master...if you have a binary can you test it?
<headius> yopp: well yes, that's true, but we pride ourselves on working around JVM oddities too :-)
<yopp> headius, with binary, yes
<headius> ok...hopefully 9.1.3.0 head runs your app ok. I'll push this and kick off a CI dist build
<headius> ...after some sanity tests
<headius> if you can reproduce the starvation, or at least see it in that graph, trying the four options from above would be very interesting
<headius> this is just going to get worse as more people move to containers
<headius> maybe there's a kernel config to bump up the entropy pool size?
<headius> "[AFAIR, the random pool is only 512 bytes in size, so it can't contain more
<headius> "entropy" than that]"
<headius> heh
<yopp> no idea, but I don't think so, otherwise there will be no havenged
<GitHub120> [jruby] headius pushed 1 new commit to master: https://git.io/v6OqE
<GitHub120> jruby/master 1b3111e Charles Oliver Nutter: Allow configuring the preferred PRNG for SecureRandom.
<yopp> because that's pretty much only solution I was able to google
<headius> yopp: whenever this finishes, you can go to ci.jruby.org and grab a 9.1.3.0 snapshot: https://projectodd.ci.cloudbees.com/view/JRuby/job/jruby-master-dist/370/
claudiuinberlin has quit [Remote host closed the connection]
<headius> the property is jruby.preferred.prng or -Xpreferred.prng passed to JRuby
<headius> -Xpreferred.prng=NativePRNGNonBlocking etc
<yopp> Kk, I'll try on Monday, I'm not in the friday-night-deploy-that-will-blow-your-weekend mood :)
<headius> yeah ok...this is HEAD too so don't put your server at risk on our account :-)
<headius> I will update related bugs with this property
<enebo> headius: you use preferred because it might be usable on all platforms?
<headius> yeah, if it can't load preferred it falls back on the default JDK logic to choose a provider
<yopp> I'll try on staging, if some of the hosts on graph will improve entropy then it's working
<headius> yopp: cool, thanks
<headius> update that when you are able to test
<yopp> but afaik rancher is running some of their stuff on the jvm as well, so maybe it's their fault
<travis-ci> jruby/jruby (master:b334224 by Benoit Daloze): The build has errored. (https://travis-ci.org/jruby/jruby/builds/150106289)
<yopp> because rancher only one common thing on this hosts, and from the graph I can tell that all of them are leaking the pool
<yopp> one the same rate
<headius> yopp: in that bug bascule points out that he's using NativePRNGNonBlocking which is new in Java 8
<headius> so maybe that's the ticket
<headius> I could certainly change master to prefer that, then try SHA1, then just let JDK decide
<enebo> headius: is that a class name or some other value on Java side?
<headius> well it's a service name out of jca provider stuff
<yopp> from the java docs it seems like NativePRNGNonBlocking is just /dev/urandom
<headius> yopp: makes sense
<headius> urandom is supposed to never block
<enebo> headius: so the provider does not allow class naems probably
<headius> I don't know :-)
<headius> this is SecureRandom.getInstance(name)
<headius> so it's doing some JCA provider lookup of some kind
<enebo> headius: otherwise we could allow people to use custom ones too and we could possible have a gem which uses one of these other packages outside JVM perhaps
yfeldblum has joined #jruby
<headius> yeah I don't know if you can install a new provider unprivileged
<headius> I guess BC is a provider but I don't know what they have for PRNG
<enebo> headius: hehe…and Java 9
<headius> call sites merged
<GitHub193> [jruby] headius merged master into java_call_sites: https://git.io/v6OYK
<GitHub170> [jruby] headius merged java_call_sites into master: https://git.io/v6OY6
<GitHub9> [jruby] headius closed issue #3976: Superclass mixin implementation called instead of subclass implementation https://git.io/voiQy
<GitHub27> [jruby] headius deleted java_call_sites at 9edd069: https://git.io/v6OYi
<headius> eregon: your last commit is still red in travis...looks like it's hanging
zacts has joined #jruby
<headius> enebo: I think I'm going to modify this to prefer the nonblocking PRNG, then SHA1, then JDK picks
<headius> zacts: g'day
<headius> did you ever get to using JRuby for anything? I remember you asked about calling libs
<enebo> headius: yeah makes sense from all things said on channel
<enebo> headius: it makes even more sense since we cannot depend on the first two existing
<zacts> hi
<zacts> headius: not quite yet
<zacts> I'm thinking of trying to utilize it with supercollider and processing
bbrowning is now known as bbrowning_away
<GitHub191> [jruby] headius pushed 1 new commit to master: https://git.io/v6OGO
<GitHub191> jruby/master 061903e Charles Oliver Nutter: Prefer non-blocking PRNG, with failover to SHA1 and then JDK def....
<headius> zacts: ahh there's a ruby-processing wrapper you might want to look at
<headius> I'm not familiar with supercollider
<zacts> oh cool
<zacts> yeah supercollider is to music synth what processing is to visuals
<headius> oh slick
<headius> yeah that would be fun to stitch together with JRuby
TheWhip has joined #jruby
<headius> bbrowning_away: hey you were seeing SecureRandom problems at one point too
<headius> I should probably just spin up a linux VM and see if I can starve it
<nirvdrum> Isn't this still the /dev/random thing?
<nirvdrum> I thought the issue was seeding the PRNG from /dev/random and the latter blocks.
<nirvdrum> We had similar reports with Selenium, FWIW.
zacts has quit [Quit: WeeChat 1.4]
<chrisseaton> headius: have you explored how JRuby interacts with Jigsaw (or Java 9 in general) yet?
<headius> nirvdrum: yes
<headius> but I did not know that Java 8 added an explicitly nonblocking PRNG
<headius> so we'll try that first now
<headius> chrisseaton: I don't think we boot on 9 yet
<headius> it's on my to-do list
<headius> I need to build jigsaw-head anyway to test out new jlink invokedynamic support
<chrisseaton> yeah suddenly panicked that it's part of our strategy to get people to use Graal via Java 9 EA, but I haven't actually been trying that
<chrisseaton> I found the JVMLS Jigsaw presentation very hard to get my head around
* yopp still impressed that CI builds went from 30m to 10m
<yopp> pull requests now 2-4m vs 10-15m
<chrisseaton> headius: Platform.initPlatform seems to be an early point of failure
<nirvdrum> headius: Interesting. And searching for that class brought me to https://tersesystems.com/2015/12/17/the-right-way-to-use-securerandom/, which describes the situation pretty well.
<chrisseaton> headius: Class.forName("com.sun.security.auth.module.UnixSystem") likely
<headius> chrisseaton: jigsaw is pretty involved
<headius> yopp: that's pretty amazing
<headius> yopp: what is it that's hitting SecureRandom so much?
<nirvdrum> In my experience, UUID has been a common source.
<headius> yeah
claudiuinberlin has joined #jruby
<nirvdrum> IIRC, Rails or Rack generates one per request.
<headius> chrisseaton: are you ficking JDK9 stuff right now or just noting what failed?
<headius> HEH
<headius> fixing
<chrisseaton> Just tried it for the first time
<chrisseaton> It seems to basically work - just where we use unusual JDK libraries it's not allowing it
<chrisseaton> Is there a big flag to turn off Jigsaw?
<travis-ci> jruby/jruby (master:d1b6d5e by Chris Seaton): The build has errored. (https://travis-ci.org/jruby/jruby/builds/150112546)
<chrisseaton> Or to allow unrestricted access to classes, more like?
<headius> I don't know
TheWhip has quit [Remote host closed the connection]
<headius> I'm doing a head build of jigsaw and will see what I can do
<headius> chrisseaton: if I wanted to get graal folks playing with JRuby classic, would I run into 9 issues?
<headius> or put another way, is graal dev being done against a JDK8 based or JDK9
<chrisseaton> GraalVM is based on 8
<headius> ok
<headius> I want to toss over some instructions for running JRuby + benchmarks and see if we can improve things
<headius> recent improvements seem to be bumping up our perf a lot...so I'd like to do more playing with graal
<headius> graal 0.12 is also dying on a few benchmarks
<headius> JRuby and J+T
<headius> managed to triple the rubykon bench without trying, just incremental improvements
<chrisseaton> Yeah I need to get Rubykon into our CI system
<headius> which CI system is that?
TheWhip has joined #jruby
<travis-ci> jruby/jruby (truffle-head:01540ce by Chris Seaton): The build was broken. (https://travis-ci.org/jruby/jruby/builds/150113431)
TheWhip has quit [Ping timeout: 250 seconds]
<chrisseaton> We have a sort of Travis like system interally
<headius> ah, so nothing public...that's too bad
<headius> I could not run JT on 0.12 so I don't know how perf has changed
<headius> my 3x was just comparing JRuby classic 9.0.3.0 to master
<chrisseaton> The benchmark results might be at some point
<chrisseaton> Like are-we-fast-yet
<chrisseaton> You should be able to run master on GraalVM 0.12 - we test and benchmark that on every commit
<headius> chrisseaton: it blows up for both JRuby and JT on rubykon
<headius> missing method, really weird
<headius> works fine on hotspot
<chrisseaton> Oh right you mean Rubykon specifically
<chrisseaton> Yeah I should look at it again and bake it into CI so it stays working
<headius> well no, I'm talking in general, but for rubykon specifically that was a problem
<chrisseaton> Especially if you're going to try to improve it further :)
<headius> especially weird that it effected both of us
<headius> oh, we're going to have some great improvements over the next couple months :-)
<headius> I figure if I can get a few more object shape specializations in, and we get our specialization+deopt+inlining story working, we should be looking a lot better
claudiuinberlin has quit [Remote host closed the connection]
<headius> especially if graal is less annoying about inlining thresholds
<chrisseaton> Are HotSpot's configurable?
claudiuinberlin has joined #jruby
<headius> yes
<headius> but usually it makes something else worse
<headius> I have benchmarks that are 2-3x faster if I tweak InlineSmallCode, for example
<headius> it kinda makes you wonder how much perf we're losing out on because Hotspot is too conservative
<headius> chrisseaton: what's the graal property to print all flags?
<headius> -G stuff doesn't work anymore
camlow325 has quit [Read error: Connection reset by peer]
<headius> all the graal pages seem really out of date
camlow325 has joined #jruby
<chrisseaton> -G should still work if you use your own launcher
<chrisseaton> otherwise -Dgraal. from now on
<chrisseaton> As the VM doesn't know that Graal exists anymore - just JVMCI
<chrisseaton> I can't remember how to print flags though
<headius> yeah I'll just used the latter
<headius> -G doesn't seem to do anything
<headius> ahh, -Dgraal.PrintFlags
<chrisseaton> That's how we translate it
<headius> ahhh I see
<headius> I was doing -J-G
<headius> bypassing
camlow32_ has joined #jruby
camlow325 has quit [Read error: Connection reset by peer]
<headius> chrisseaton: we need to get that in native launcher also...
<chrisseaton> Well actually we were thinking of getting rid of -G - it was there to match GraalVM, but now they use those properties
<chrisseaton> I need to check if any of our options need to go into the native launcher though
<headius> hmm, that flag isn't dumping anything either
<headius> frustrating
<chrisseaton> Let me try...
<chrisseaton> Do you mean dumping to IGV?
<headius> I'm just trying to get the list of flags
<headius> nothing does anything
<headius> 0.12 oracle graal
<chrisseaton> I think the problem is Graal won't look for flags until it is loaded
<headius> sure, but why wouldn't it be loading?
<headius> Chris T told me I needed to force a compilation, but this is running for minutes with no output from graal
<headius> I'm not using the Graal wrapper around javao
<headius> my graal `java` is linked to javao
<headius> chrisseaton: which repo should I build for graal head?
TheWhip has joined #jruby
<chrisseaton> graal-core
<headius> ok
<chrisseaton> I never use Graal to compile Java code so I'm not sure myself
<headius> the old hotspot flags work...I feel like this isn't using graal for JRuby classic anymore
<chrisseaton> just trying it myself...
<headius> it seems to work for JT...roughly 2.5x faster than classic
<headius> at least on the benches I'm trying
<chrisseaton> So back up - what are you trying to do? JT doesn't run Graal to compile Java
<chrisseaton> So that working doesn't tell us anything
TheWhip has quit [Ping timeout: 276 seconds]
<headius> I'm trying to use graal to run JRuby classic
e_dub has quit [Quit: ZZZzzz…]
<chrisseaton> Are you using your launcher?
<headius> I thought oracle graal would do that
<headius> yes
<chrisseaton> Try without that - I think it sets -server by default, which may turn off Graal
<headius> ah that could be
<enebo> perhaps we need more output in -v :)
<enebo> it seems like we have all run the wrong thing at one time now
<headius> still nothing
<headius> calling java directly with -graal and -Dgraal.PrintFlags=true
<headius> chrisseaton: by capital "JT" I just mean JRuby+Truffle, not using your jt script
<chrisseaton> yeah
<headius> in case that was unclear
<chrisseaton> But ignore that because it doesn't use Graal in the same way at all, so the configuration etc is totally different
<headius> sure
<headius> this may explain why I stopped seeing the fractal bench improvements
<headius> I can't see any evidence this JDK is using graal to compile anything
<headius> OpenJDK 64-Bit Server VM (build 25.66-b00-graalvm-0.12, mixed mode)
<chrisseaton> wait wait wait I know this... one minute
<headius> tried turning off tiered, nothing
<headius> java -Djruby.home=`pwd` -XX:-TieredCompilation -graal -Dgraal.PrintFlags=true -Djruby.compile.invokedynamic -jar lib/jruby.jar ...
<headius> my incantation has not summoned up a graal demon
<chrisseaton> -Djvmci.Compiler=graal
<chrisseaton> not working for me - sorry that was a guess
<headius> yeah nothing :-(
<headius> I'll ask Chris T
enebo has quit [Quit: enebo]
<chrisseaton> Well let me know when you figure it out
<chrisseaton> I should know this stuff!
<chrisseaton> -J-XX:+UnlockExperimentalVMOptions -J-XX:+EnableJVMCI
<chrisseaton> That might be needed, but can't see why GraalVM doesn't have that by default
<headius> he thinks 0.12 is too old, but even the old flags don't work
<GitHub123> [jruby] eregon pushed 1 new commit to master: https://git.io/v6OzL
<GitHub123> jruby/master be2b945 Benoit Daloze: [Truffle] Slow tags.
<chrisseaton> Hmmm yeah it is months old actually
<chrisseaton> Let me try with what I built from source
<chrisseaton> Before you waste your time trying that...
<headius> ok
<headius> the mx repo is surprisingly large for a bunch of python scripts
camlow325 has joined #jruby
<headius> shutil.Error: [('/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/server/hsdis-amd64.dylib', '/Users/headius/projects/graal/graal-jvmci-8/jdk1.8.0_92/product/jre/lib/server/hsdis-amd64.dylib', "[Errno 13] Permission denied: '/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/server/hsdis-amd64.dylib'")]
<headius> god dammit.
camlow32_ has quit [Read error: Connection reset by peer]
<headius> I guess I'll remove my disassembly lib for now
<headius> seems to be building now
<headius> permissions must have been wonky
<travis-ci> jruby/jruby (master:50882dc by Thomas E. Enebo): The build has errored. (https://travis-ci.org/jruby/jruby/builds/150135524)
camlow325 is now known as 5EXAA3TAH
camlow325 has joined #jruby
camlow325 has quit [Remote host closed the connection]
<chrisseaton> I was missing -XX:+UseJVMCICompiler
<chrisseaton> But now I get JVMCI compiler 'graal' not found
<chrisseaton> JAVACMD=../../graal/graalvm-0.12-dk/bin/java bin/jruby -J-server -J-XX:+UnlockExperimentalVMOptions -J-XX:+EnableJVMCI -J-XX:+UseJVMCICompiler -J-Djvmci.Compiler=graal -J-Dgraal.PrintFlags=true ../test.rb
<chrisseaton> bingo!
<chrisseaton> I'm writing that down
<chrisseaton> Works on 0.12 as well
<headius> awesome
<headius> ok cool
camlow325 has joined #jruby
<headius> FLAGS!!
<headius> wow that was way more painful than I expected
camlow325 has quit [Remote host closed the connection]
5EXAA3TAH has quit [Ping timeout: 244 seconds]
<headius> heh... I do not recommend -graal...minutes to start up
<chrisseaton> Bootstrapping?
camlow325 has joined #jruby
<headius> yeah
<headius> bleh...this is still dog slow
TheWhip has joined #jruby
<chrisseaton> Would be cool if you turn Graal on just for your generated bytecode
<headius> yeah, I'm trying to get familiar with it now and see what we can discover
<headius> if it's inlining through indy sites and partial EA is working I should be seeing better results
<chrisseaton> You need to actually sit down with a Graal person for a couple of days and see what you can get out of it
<headius> I can't get this thing to run any bench faster
<headius> yeah, I'll probably be bugging Chris T a lot over the next weeks
<headius> I'll get something together to post to graal-dev too
<chrisseaton> It's probably the indy - which we don't exercise much
<chrisseaton> And if that blocks something it would block everything in JRuby generated code
TheWhip has quit [Ping timeout: 244 seconds]
<headius> yep
<headius> indy is nonnegotiable for us
<chrisseaton> But leaving that aside for a second, is it faster on Graal without it?
<headius> well let me see
<headius> it's definitely slower with indy on
<headius> roughly equivalent perf without indy on
<headius> this is still 0.12 keep in mind
claudiuinberlin has quit []
camlow32_ has joined #jruby
camlow32_ has quit [Read error: Connection reset by peer]
camlow32_ has joined #jruby
camlow325 has quit [Ping timeout: 276 seconds]
<headius> still slow with head
<travis-ci> jruby/jruby (master:9edd069 by Charles Oliver Nutter): The build has errored. (https://travis-ci.org/jruby/jruby/builds/150141932)
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 244 seconds]
camlow32_ has quit [Remote host closed the connection]
camlow325 has joined #jruby
e_dub has joined #jruby
e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
camlow325 has quit []
TheWhip has joined #jruby