e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
TheWhip has joined #jruby
mistergibson has joined #jruby
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 276 seconds]
zacts has joined #jruby
mistergibson has quit [Quit: Leaving]
TheWhip has quit [Remote host closed the connection]
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 264 seconds]
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 246 seconds]
TheWhip has joined #jruby
TheWhip has quit [Ping timeout: 260 seconds]
e_dub has quit [Quit: ZZZzzz…]
nirvdrum has joined #jruby
TheWhip has joined #jruby
e_dub has joined #jruby
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 250 seconds]
TheWhip has quit [Remote host closed the connection]
yfeldblum has quit [Remote host closed the connection]
pawnbox has joined #jruby
thedarkone2 has quit [Quit: thedarkone2]
zacts has quit [Ping timeout: 272 seconds]
nirvdrum has quit [Ping timeout: 252 seconds]
pawnbox has quit [Ping timeout: 246 seconds]
sebstrax has quit [Quit: Connection closed for inactivity]
pawnbox has joined #jruby
zacts has joined #jruby
pawnbox_ has joined #jruby
pawnbox has quit [Ping timeout: 240 seconds]
TheWhip has joined #jruby
odix67 has joined #jruby
zacts has quit [Ping timeout: 264 seconds]
yfeldblum has joined #jruby
bga57 has quit [Quit: Leaving.]
pawnbox_ has quit [Remote host closed the connection]
pawnbox has joined #jruby
zacts has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
zacts has quit [Ping timeout: 240 seconds]
prasunanand has joined #jruby
donV has joined #jruby
zacts has joined #jruby
prasun has joined #jruby
prasunanand has quit [Ping timeout: 246 seconds]
pilhuhn has joined #jruby
pawnbox has quit [Remote host closed the connection]
TheWhip has quit [Remote host closed the connection]
pawnbox has joined #jruby
prasunanand has joined #jruby
prasun has quit [Quit: Leaving]
raeoks has joined #jruby
pawnbox has quit [Ping timeout: 272 seconds]
olleolleolle has joined #jruby
skade has joined #jruby
zacts has quit [Read error: Connection reset by peer]
olleolleolle has quit [Quit: olleolleolle]
zacts has joined #jruby
elia has joined #jruby
prasunanand has quit [Ping timeout: 246 seconds]
rsim has joined #jruby
Hobogrammer has quit [Ping timeout: 276 seconds]
zacts has quit [Ping timeout: 250 seconds]
nirvdrum has joined #jruby
pawnbox has joined #jruby
TheWhip has joined #jruby
Hobogrammer has joined #jruby
zacts has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
elia has quit [Quit: Computer has gone to sleep.]
odix67 has quit [Quit: Leaving.]
elia has joined #jruby
elia has quit [Quit: Computer has gone to sleep.]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
ebarrett has joined #jruby
yfeldblum has quit [Ping timeout: 250 seconds]
pawnbox has quit [Remote host closed the connection]
TheWhip has quit [Remote host closed the connection]
TheWhip has joined #jruby
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
<snim2->
chrisseaton, sorry to bother you, but I'm having difficulty enabling truffle/graal with the current truffle-head branch. Should I be using v13 of graal now that it is tagged in the repo? To give you some context this is how I have been building / verifying JRuby: https://gist.github.com/snim2/66bad88d694994877553bb826323b7a8
pawnbox has joined #jruby
<chrisseaton>
snim2-: master still uses GraalVM 0.12
<chrisseaton>
what's your symptom?
<chrisseaton>
oh sorry i see it at the bottom there
<snim2->
Line 38: RuntimeError: Failed to find Truffle.graal? attribute; I've tried a couple of different flags
<chrisseaton>
You're using truffle-head, can you remember if there's a reason for that?
<chrisseaton>
Try using master
<snim2->
OK, thanks, will have a go now
tcrawley-away is now known as tcrawley
pawnbox has quit [Ping timeout: 258 seconds]
pawnbox has joined #jruby
<snim2->
chrisseaton, thanks, I hadn't realised the truffle changes were being merged so fast. On master branch I can get -J-G:+TraceTruffleCompilation to produce output, but oddly our jit_test program still raises a name error. Has the API changed?
elia has joined #jruby
bbrowning_away is now known as bbrowning
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
zacts has quit [Ping timeout: 264 seconds]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
prasunanand has joined #jruby
<chrisseaton>
newBuilder is only on truffle-head, so you either must still be on that branch, or you need to rebuild
zacts has joined #jruby
<snim2->
hmm. Git status says I am on master, and I did rebuild, but I'll clean and rebuild again and see what happens
<chrisseaton>
Let me check I'm telling you the right thing...
<snim2->
I've tried rebuilding and flags "-X+T", "-J-Djvmci.Compiler=graal" and both of those, and get the same result. So perhaps our test case is now out of date?
<chrisseaton>
it probably won't ever be included, but it should be compatible with JDK 9 ea - hopefully the next build
<bascule>
| ___| _ \|_ _| _ \ / \\ \ / / | | |
<bascule>
| |_ | |_) || || | | |/ _ \\ V /| | | |
<bascule>
| _| | _ < | || |_| / ___ \| | |_|_|_|
<bascule>
|_| |_| \_\___|____/_/ \_\_| (_|_|_)
<bascule>
<chrisseaton>
so you'll use JDK 9, and then get Graal from maven or shaded or whatever
<donV>
chrisseaton: Hmm, ok, thanks.
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
pawnbox_ has joined #jruby
pawnbox has quit [Ping timeout: 258 seconds]
<chrisseaton>
donV: it'll be just like attaching a Java agent
<chrisseaton>
I'll post to the mailing list when it's possible
zacts has joined #jruby
<donV>
chrisseaton: cool, thanks.
<donV>
chrisseaton: any thoughts on how to make it über-easy to use with jruby+truffle? Any extra install step raises the threshold.
<chrisseaton>
the easiest is use GraalVM, which is a bundle including everything you need in a tarball
<chrisseaton>
But when JDK 9 is out, we just have to say 'use a recent JVM and these flags' - we can probably do something in the launcher
<donV>
chrisseaton: and the graal.jar?
<chrisseaton>
we could perhaps bundle that (it isn't huge), I'm not sure yet
<chrisseaton>
GraalVM would be the way I would recommend to anyone at the moment
<chrisseaton>
It should be possible to make that work with ruby-build, ruby-install, rvm etc
<chrisseaton>
It's going to get a little more complex as well as we're going to rely on another Truffle interpreter, Sulong, to run C extensions
<chrisseaton>
That's optional at the moment, but since almost everyone depends on openssl which is native it isn't really optional
rcvalle has joined #jruby
prasunanand has quit [Ping timeout: 240 seconds]
lanceball is now known as lance|afk
thedarkone2 has joined #jruby
griest has joined #jruby
<griest>
can the max Java heap size be set through .jrubyrc?
elia has joined #jruby
<enebo>
chrisseaton: could jt grab it?
<chrisseaton>
jt could, but that's just for development
<enebo>
chrisseaton: yeah I am just thinking of a vector to make this really simple for people playing
<enebo>
chrisseaton: don’t you still need jt to install gems?
<enebo>
chrisseaton: at least get the .gem file
<chrisseaton>
oh you mean the runtime tool, rather than the build tool
<chrisseaton>
yeah, it could do that
<chrisseaton>
hopefully ruby gems will work soon when openssl is running
<enebo>
cool
<enebo>
chrisseaton: let’s try and remember to sync up before 9.1.3.0 is put out so hopefully we can give more instrs for people to try out truffle backend
<chrisseaton>
when will that be?
<enebo>
chrisseaton: hopefully 9ea and 9.1.3.0 will line up
<enebo>
chrisseaton: no specific date since we have been taking some time to try and advance some longer goals and not fixing many buigs
<enebo>
chrisseaton: but definitely in the next month … hopefully quite a bit sooner
<enebo>
chrisseaton: I guess we need to reexamine what is marked against it to make that determination
<enebo>
chrisseaton: I just want to make sure I don’t miss out on advertising this new milestone
<enebo>
chrisseaton: since 9ea will make it one step easier to get started
<enebo>
chrisseaton: or perhaps not one less step but closer to the real step once 9 is fully out
lance|afk is now known as lanceball
<chrisseaton>
I wish there was a command line 'maven install com.oracle.graal:graal:1.0'
<chrisseaton>
Then I could just tell people to run that and then find it in ~/.m2
<enebo>
chrisseaton: yeah I wonder how automated we could do this? maybe jruby -X+T could execute the download if not done
<enebo>
chrisseaton: that might be a bit weird perhaps
<chrisseaton>
And I think our only Graal binaries at the moment are as part of GraalVM, which is click-through
<enebo>
I guess I don’t know how far htings are by the point -X+T is processed either
<enebo>
chrisseaton: oh that will make it a little painful
<enebo>
chrisseaton: will that ever change?
<chrisseaton>
that's because they're built on OracleJDK
<enebo>
chrisseaton: I guess java itself is like that
<chrisseaton>
yes I think anyone can build and distribute graal.jar, so maybe we should be doing that
<enebo>
chrisseaton: how big is it?
<chrisseaton>
GraalVM? The DK is 500MB uncompressed
<chrisseaton>
It includes JRuby
<enebo>
I mean graal.jar
<enebo>
isn’t that all that is needed for jvm 9?
<chrisseaton>
12 MB
<chrisseaton>
No there's a few other jars
<enebo>
ah ok
<chrisseaton>
A bit of a long classpath
<enebo>
I was just wondering how much it would bloat our bin dist
<enebo>
sounds like quite a bit
<chrisseaton>
yeah, we'll have a think about it
<enebo>
chrisseaton: we could always consider a truffle binary release too but I was sort of hoping we could not keep increasing how many things we release :)
<GitHub25>
jruby/master db308fe Brandon Fish: [Truffle] Return StopIteration#result from loop
zacts has quit [Ping timeout: 264 seconds]
sebstrax has joined #jruby
prasunanand has joined #jruby
bbrowning is now known as bbrowning_away
lanceball is now known as lance|afk
<cprice404>
hi all, i saw the tweet about EOL for JRuby 1.7. is there a roadmap anywhere that covers perf improvements / goals for things in 9k that are currently slower than 1.7?
<enebo>
cprice404: there is no specific document no but your project in particular have us looking into overhead of starting scriptingcontext
<enebo>
weirdly I am looking at a small bench which loads prime.rb over and over to see why the timings are different
<enebo>
this bench will parse nearly same speed but the load is almost 3x slower
<enebo>
but a cpu profile shows them dominated by parsing which runs the same speed
prasunanand has quit [Remote host closed the connection]
<enebo>
I am guessing maybe it is allocation of some kind not showing up in cpu profiling
<cprice404>
interesting
<enebo>
cprice404: we do have some really interesting tiny improvements for parsing we discovered
<cprice404>
well, we are definitely eager to make the switch
<enebo>
they are going to be a few percent here and there but those are not the bulk of this difference
<cprice404>
and as much as we are able to we are happy to help test things and provide additional benchmarks
<enebo>
really it will just make us beat old parser vs new parser
<enebo>
something else is killing time
<cprice404>
gotcha
<enebo>
cprice404: yeah a scripting container bench which is a typical amount of code would be useful
<enebo>
cprice404: if it matches how you code it internally then we will also examine whether there is something else we can do to make your architecture work better
<cprice404>
enebo: is it ok if the repo for the reproducer contains a very large amount of ruby code? :)
<cprice404>
we've been trying to keep the reproducers we submit as minimal as possible, thinking that would be easier for you guys to work with
<cprice404>
but we could submit one that actually includes the puppet source code and does some stuff with it if it would help
<cprice404>
tbh that reproducer that we submitted with the json.pure thing is by far our biggest hit at the moment
<enebo>
cprice404: I think amount of code is ok if the main bulk of hotspot is a small portion of that code
<enebo>
cprice404: ah yeah I do remember that
<enebo>
cprice404: although in that case it might be more CPU bound for us
<cprice404>
yeah, i think if we submitted one with real-world calls to the puppet code it'd be lots of different hot spots, so might just be hard to sort signal from noise
<enebo>
you run json.pure using our interp
<enebo>
well you only use our interp for all
<cprice404>
we use compile-mode: OFF by default for everything
<cprice404>
we are trying to do some experiments with compile-mode: JIT
<enebo>
I would like to see if we can use JIT and tune things
<cprice404>
but it's challenging for us to use that mode unfortunately
<chrisseaton>
how come? not enough memory?
<cprice404>
FWIW JIT didn't make much difference in that JSON reproducer.
<enebo>
I wish we had some record and persist VM and a particular point in time
<cprice404>
memory is one issue
<cprice404>
or biggest issue, though, is that we allow users to write ruby extensions to our code
<cprice404>
and they may contain memory leaks
<cprice404>
and the only way for us to prevent OOMs in that case is to recycle ScriptingContainers occasionally
<cprice404>
so, when we turn JIT on, the warmup costs are big, and we incur them every time we flush and instantiate a new ScriptingContainer
<cprice404>
it ends up using a lot more memory *and* being slower
<cprice404>
so that's not a great combo for us :)
<enebo>
cprice404: we used to have a code cache for this problem
<enebo>
cprice404: I believe we eliminated it between 1.6 and 1.7
<cprice404>
we're trying to see if we can reduce the number of times we recycle those ScriptingContainers, which may work for many of our users
<enebo>
cprice404: but then all compiled code would get shared across runtime instances (e.g. scrpting containers)
<cprice404>
would that be bad?
<enebo>
cprice404: but that ended up acculmulating a lot of compiled code and no one used the feature
<cprice404>
gotcha
<cprice404>
yeah, i recognize we're a bit of an outlier with this requirement
<enebo>
cprice404: well Sun used it but Kenai is dead and they switched off niagara
<cprice404>
but most of our users are sysadmins so we can't always get away with saying "just don't write code with memory leaks!" since software dev isn't really their main background
<enebo>
cprice404: yeah so for memory IR Jitting will use less memory soonish
<enebo>
cprice404: so that hopefully will make us near 1.7 or better there
<cprice404>
that's good
<enebo>
cprice404: that may not help you though
<cprice404>
do you think the interpreter will ever be able to be brought up to par with the 1.7 one? or is that unlikely because of implementation differences?
<enebo>
cprice404: at this point I think it is unlikely it will get much faster
<cprice404>
ok, gtk.
<cprice404>
whoops, have to run to a meeting, thanks for the info, will peek back in here later
<enebo>
cprice404: we have thought about moving back to AST interp but that might be a last ditch thing
<enebo>
IR is really good for compilation and not so good at interp
<chrisseaton>
can't you compile from IR to something simpler and faster to run?
pawnbox_ has quit [Read error: Connection reset by peer]
pawnbox has joined #jruby
subbu is now known as subbu|lunch
<enebo>
chrisseaton: yeah we talked about that but then our startup pipeline is even longer
<headius>
back from lunch, howdy
<headius>
rtyler: I think your issue is in JRuby
<headius>
drbrain showed me where MRI builds the extconf command line and it uses Gem.ruby...which we overwrite with a version that can build up the java command if necessary