pawnbox has quit [Remote host closed the connection]
enebo has joined #jruby
enebo has quit [Client Quit]
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 244 seconds]
camlow325 has quit [Quit: WeeChat 1.5]
raeoks has joined #jruby
esmiurium has quit [Ping timeout: 250 seconds]
esmiurium has joined #jruby
etehtsea has joined #jruby
zacts has joined #jruby
etehtsea has quit [Client Quit]
etehtsea has joined #jruby
pawnbox has joined #jruby
zacts has quit [Ping timeout: 240 seconds]
pawnbox has quit [Ping timeout: 250 seconds]
<GitHub190>
[jruby] bjfish deleted truffle-thread-name at 443d95a: https://git.io/vivQA
<GitHub79>
[jruby] nirvdrum pushed 2 new commits to truffle-head: https://git.io/viv7v
<GitHub79>
jruby/truffle-head 622897f Kevin Menard: [Truffle] Reworked String#+ with a RopeBuffer receiver to avoid an unnecessary memory allocation and copy....
<GitHub79>
jruby/truffle-head 900d8ac Kevin Menard: [Truffle] Fixed String#dup for RopeBuffers.
enebo has joined #jruby
enebo has quit [Client Quit]
raeoks has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<GitHub107>
[jruby] kares closed issue #3801: [ji] make java.util.Date duck type some of Ruby's Time https://git.io/vVjC8
rsim has quit [Ping timeout: 252 seconds]
subbu|lunch is now known as subbu
dinfuehr_ has joined #jruby
rsim has joined #jruby
<cprice404>
dear JRuby peeps: thanks much for the 1.7.26 release! a couple of those bugfixes were really big deals for us.
tcrawley is now known as tcrawley-away
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 276 seconds]
claudiuinberlin has quit [Remote host closed the connection]
claudiuinberlin has joined #jruby
claudiuinberlin has quit [Remote host closed the connection]
rsim has quit [Quit: Leaving.]
claudiuinberlin has joined #jruby
claudiuinberlin has quit [Client Quit]
bbrowning is now known as bbrowning_away
tcrawley-away is now known as tcrawley
tcrawley is now known as tcrawley-away
johnsonch is now known as johnsonch_afk
pawnbox has joined #jruby
nicksieger has quit [Remote host closed the connection]
pawnbox has quit [Ping timeout: 240 seconds]
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
tcrawley-away is now known as tcrawley
dinfuehr_ has quit [Remote host closed the connection]
pawnbox has joined #jruby
tcrawley is now known as tcrawley-away
pawnbox has quit [Ping timeout: 255 seconds]
johnsonch_afk is now known as johnsonch
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 255 seconds]
tcrawley-away is now known as tcrawley
<chrisseaton>
cprice404: what keeps you on 1.7?
<cprice404>
chrisseaton: I added our links to that issue on the jruby issue tracker. The biggest one is leaking file descriptors when using multiple ScriptingContainers
<cprice404>
beyond that it's mostly just perf regressions and memory usage increases
<cprice404>
#3928 is the file descriptor leak issue
<cprice404>
#3922 and #3921 are the biggest perf regressions we've charactized so far
<chrisseaton>
Why do you care about memory usage? Are you on cloud instances with low memory so you don't have much head room? (asking because I'm interested in trading off memory with performance)
<cprice404>
we're on-prem
<cprice404>
so we ship packages to customers and they have to run our stuff in their environments
<cprice404>
they are already mad at us because they think JRuby 1.7 uses a lot more memory than our previous versions that ran on Passenger w/MRI
<cprice404>
I don't know if that impression is actually accurate, but because of how passenger worked in terms of memory management, the memory usage was much less visible to them
<cprice404>
as compared to a JVM process that will OOM if you don't have a sufficient Xmx
<cprice404>
but in our testing we've definitely seen a pretty drastic jump in heap space requirements moving from 1.7.x to 9k
<chrisseaton>
Do you think many of them run multiple instances, and might be better off with one instance, perhaps using more memory, but serving many more users faster?
<cprice404>
we're a pretty weird use case though because of our use of multiple ScriptingContainers... thus the memory increase is multiplied for us
<chrisseaton>
I think one limitation people have is they want to use $5 DO droplets with 250 MB of RAM or whatever
<cprice404>
heh, well, our app is also very CPU intensive
<cprice404>
so scaling up means you need more CPU *and* more RAM, regardless of whether you scale horizontally vs increasing the hardware on a single instance
<chrisseaton>
Is it CPU intensive actually inside the Ruby interpreter? Or in an extension?
<cprice404>
so with #3922 and #3921, jruby9k means they need more CPU too.
<cprice404>
it's inside the ruby interpreter
<cprice404>
there are certainly optimizations we can make on our end, and we're trying to do that over time, but it's hard to do it w/o breaking backward compat so those changes take time
<chrisseaton>
You use scripting containers for isolation don't you?
<cprice404>
correct
<cprice404>
it would be amazing if we could get rid of that
<cprice404>
but the legacy ruby code we currently have to run it has a lot of global state
<chrisseaton>
We're working on isolated runtimes, but shared (invisible to you) optimised code, and some new ideas like enforced time boxing
<cprice404>
that sounds awesome
<cprice404>
this is for truffle I presume?
<chrisseaton>
Yeah
<cprice404>
cool, definitely looking forward to playing with it
<chrisseaton>
Is any of your code, or anything like it, available publicly?
<cprice404>
chrisseaton: it's all open source, I'll grab a link... it's kind of confusing to understand and run at first though
<chrisseaton>
Thanks, I might try to use your use case as something to aim at
<cprice404>
the main app is clojure; it spins up a pool of JRuby scriptingcontainers to run ruby code though
<chrisseaton>
Ah polyglot! Even better
<cprice404>
yeah :/
<chrisseaton>
Is time boxing interesting to you?
<chrisseaton>
As in run a script for at most 100ms, and if it times out kill it reliably
<cprice404>
yeah that might be useful, assuming it cleans up state that may have been left behind in the scriptingcontainer afterward
<cprice404>
the cleaning up state part is actually the more important bit for us
<cprice404>
we provide ruby extension points that our users can hook into with their own code
<cprice404>
and they tend to do things like leak memory :)
<cprice404>
so we have to flush the scriptingcontainers occasionally and create new ones to try to counteract that
<chrisseaton>
So how is a puppet script (that's server configuration, isn't it?) CPU intensive?
<cprice404>
we have a central server that is responsible for parsing a bunch of the user's "puppet code", and "compiling" it into a "catalog", which basically a directed graph that we then send out to the other servers to tell them what state they should be in
<cprice404>
parsing the puppet code and building the DAG are expensive
<cprice404>
partially because they're actually expensive, partially because the ruby code that does that is just not very well optimized
hobodave has quit [Ping timeout: 244 seconds]
<cprice404>
if it was super inexpensive to create a "faux" scriptingcontainer every time we needed to execute ruby code, and use a timeout feature like you described, and know that after that thing was thrown away it would release any references to memory that had been allocated during the script execution, that'd be fantastic
pawnbox has joined #jruby
<cprice404>
i guess maybe more importantly - if we could achieve good isolation w/o having to incur the full memory overhead of having a bunch of separate scripting containers, then our memory requirements would go down by something like 8x, in which case the kind of memory increase that we see in jruby9k vs jruby1.7 for a single ScriptingContainer would end up being just a drop in the bucket and our overall memory requirements would probably go down
<chrisseaton>
it looks like you have no runtime deps in your Gemfile - is that right or am I not looking in the right place?
pawnbox has quit [Ping timeout: 255 seconds]
<cprice404>
chrisseaton: ugh. this is embarrassing to explain because of the polyglot :)
<cprice404>
chrisseaton: that Gemfile is only used for testing, correct. And at present, we have no gem dependencies at runtime - BUT
<cprice404>
we provide a CLI tool that users can use to install their own gems once they've installed our app,
<cprice404>
because they are able to use gems in the extensions that they write for our app.
<cprice404>
dunno if that makes any sense :)
<chrisseaton>
no gems required at runtime - sounds very promising that maybe we could run it (obviously not real client code then if that has arbitrary deps)
<chrisseaton>
do you mind if I email you with probably lots of questions at some point in the future? I might try to get this running
<cprice404>
one of the things I'm hoping to get time for before too long is to re-wire our packaging a bit so that we could expose a configuration option to allow users to toggle between Jruby 1.7 and 9k. assuming we get that working, I'm guessing toggling to truffle would probably be an easy add-on from there.
<cprice404>
I would not mind at all!
<chrisseaton>
yeah that'd be great
<cprice404>
Though I might CC: some of my teammates once you do!
<chrisseaton>
At the moment we've been discussing the Truffle polyglot VM API and the isolation and sharing stuff somewhat in the abstract, so a use case would settle some bike shedding and set some priorities
<cprice404>
but parts of it are probably a little light on details if you're not too familiar with puppet, so, definitely if you have any questions we'd be happy to help
<chrisseaton>
would it be easy to make something representative of the user code that you need to run but that doesn't use anything exotic (or really anything at all) from gems?
<chrisseaton>
I don't really know ops (or any real world dev stuff) at all!
<chrisseaton>
But I should learn
<cprice404>
chrisseaton: mostly if you get the server running from source, you can just run some curl commands to the HTTP API endpoints to trigger the execution of some reasonably representative ruby code
<cprice404>
i can give you examples of representative curl commands if you get to that point
<cprice404>
one other thing that might be worth pointing you at is this:
<cprice404>
we've basically extracted out all of the code that pools the scripting containers to this library
<cprice404>
which is consumed by the other project.
<cprice404>
that's less of an end-to-end example of how users run our code, but probably simplare to wrap your head around if you are just trying to see how we use the ScriptingContainers.