GitHub30 has joined #jruby
GitHub30 has left #jruby [#jruby]
<GitHub30> jcodings/master 592a79c Marcin Mielzynski: add test for CASE_FOLD_TURKISH_AZERI
<GitHub30> [jcodings] lopex pushed 1 new commit to master: https://git.io/vxdtt
xardion has quit [Ping timeout: 276 seconds]
xardion has joined #jruby
careta has joined #jruby
careta has quit [Ping timeout: 240 seconds]
careta has joined #jruby
careta has quit [Ping timeout: 264 seconds]
Puffball has joined #jruby
akp has quit []
careta has joined #jruby
careta has quit [Quit: Leaving]
claudiuinberlin has joined #jruby
shellac has joined #jruby
lazyatom has joined #jruby
bbrowning_away is now known as bbrowning
claudiuinberlin has quit [Ping timeout: 264 seconds]
sidx64 has joined #jruby
Puffball has quit [Remote host closed the connection]
sidx64_ has joined #jruby
sidx64_ has quit [Client Quit]
sidx64 has quit [Read error: Connection reset by peer]
sidx64 has joined #jruby
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sidx64 has joined #jruby
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sidx64 has joined #jruby
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby
kitallis has quit [Quit: going, bye]
eonwe has quit [Remote host closed the connection]
fidothe has quit [Quit: ~]
machty has quit [Quit: ~]
fidothe has joined #jruby
Scorchin has quit [Quit: ~]
Scorchin has joined #jruby
machty has joined #jruby
deathy has quit [Quit: ~]
deathy has joined #jruby
knowtheory has quit [Quit: ~]
knowtheory has joined #jruby
zph has quit [Quit: ~]
zph has joined #jruby
akp has joined #jruby
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sidx64 has joined #jruby
<GitHub145> [jruby] yeryer opened issue #5133: Puma incompatible after JRuby 9.1.14.0 https://git.io/vxFsR
snowp has quit [Quit: ~]
snowp has joined #jruby
duncanm has quit [Quit: ~]
duncanm has joined #jruby
<GitHub140> [jruby] enebo pushed 1 new commit to jruby-9.1: https://git.io/vxF8D
<GitHub140> jruby/jruby-9.1 c5ddf24 Thomas E. Enebo: Fixes #5084....
<GitHub116> [jruby] enebo closed issue #5084: Error when installing 9.1.16.0 on Windows 10 (64 Bit) https://git.io/vxesk
shellac has quit [Remote host closed the connection]
<lopex> enebo: I think we need to pin some symbols to rutime (for options)
<enebo> lopex: what
<lopex> enebo: there's some places where we check against newSymbol("foo") == option
<enebo> do we do it a lot?
<lopex> enebo: we could lazily create them somewhere on runtime
<lopex> enebo: on IO and on casemapping
<enebo> The one totally safe place for pinning a symbol is on Ruby
<lopex> quite a few cases
<enebo> lopex: can you show me one just so I get a better understanding
<lopex> enebo: yeah, also safe to create them lazily
<lopex> enebo: since at wors there will be multiple calls to newSymbol
<lopex> enebo: so threads cannot break it
<enebo> lopex: but it will be the same instance anyways
<lopex> right ?
<lopex> yes
<lopex> that's ok
<enebo> lopex: can you show me where so I get a better idea
<lopex> and reference assignment i s atomic
<enebo> this is new code I am guessing
akp has quit [Remote host closed the connection]
<lopex> enebo: but also in IO for those read/write modes
<enebo> lopex: ah I see
<lopex> enebo: mri just uses globals here
<enebo> lopex: you may just want to accept .equals() on those instead of ==. We will definitely inline but it will make it more future proof
akp has joined #jruby
<lopex> enebo: but we could pin them them lazily on runtime without any sync
<enebo> lopex: lazy is not worth it
<lopex> not even volatile
<enebo> lopex: if you are making 4-5 symbols there is no point
<lopex> enebo: well, we could compare against interned strings too
<enebo> lopex: but you have to make a intern'd string out of an IRubyObject?
<lopex> enebo: why lazy isnt worth it ?
<lopex> it would be a ref compare then
<enebo> lopex: why add the code when you can just initialize
<enebo> lopex: memory?
<enebo> lopex: startup time?
<enebo> lopex: I mean if we did this for thousands upon thousands of things
<enebo> lopex: with that said if you want lazy that is ok
<lopex> well, yeah
<enebo> lopex: but I defer to you
<lopex> but it's not something you create on every startup
<lopex> enebo: but jsut to reassure it wouldnt have to be synced right ?
<lopex> sync is not worth definitely
<enebo> so long as you get something back no but look at newSymbol and descendants. I do not think you can get the the same symbol added twice
<lopex> enebo: also I forgot, can you mix rest and non rest @JRubyMethods ?
<enebo> lopex: someone else recently asked me that and I don't think you can but I don't really remember
<enebo> lopex: I have not done that in such a long time I only have an psychic recollection it does not work but I won't bet my life :)
<lopex> enebo: I think I'll split the case mapping since "casecmp?" is a terrible client now
<enebo> lopex: but change those from == to .equals
<lopex> ok
<lopex> enebo: symbol strings are interned right ?
<enebo> lopex: the funny part of that request is it is probably less about future proofing and more about people running static analysis tools on our code base :)
<enebo> hmm
<lopex> enebo: so newSymbol("foo") will have that interned too right ?
<enebo> yeah they are
<lopex> so why not ref comparison on strings
<enebo> look at RubySymbol.createSymbol
<enebo> I never really thought this through on bytelist_love
<enebo> do we still need an internedString
<lopex> enebo: this will come more often now
<enebo> we definitely look up using Strings in method table so probably the best thing
<enebo> lopex: I think symbol comparison is a better way than ripping out an intern'd string
<enebo> lopex: I think the bigger long term problem is sitecaching those values
<enebo> lopex: you pick Ruby and that is a place where they can live but it would be nice if we had a nice way of specifying we want a cached symbol at a point in our program
<enebo> lopex: Charlie and I talked about Remi Forax's Mjollnir library for site caching callsites but using a bytecode rewriter
<enebo> I am still into the idea but doing some benching on AR I noticed with full indy on the first iter as 20s vs 12s on a bench which gets down to 1s
<enebo> so indy and warmup still seem to be an issue on java 8
<enebo> perhaps 9+ is a lot better
<enebo> (and obviously not all of that overhead is from indy in either 12 or 20 but it seemed high)
<lopex> wasnt that Mjollnir just a dsl ?
<enebo> anyways something like sym("case_fold") which maybe rewrites as a cached field which maybe translates to runtime.getCaches().getSymbolcase_fold().
lazyatom has left #jruby [#jruby]
<enebo> lopex: it is a DSL which is lacking the rewriting part
<enebo> lopex: so it would take some more work beyond what it provides
<enebo> lopex: but the context of the conversation is Java native exts like arjdbc where if we see foo.callMethod(...) we replace it with a proper callsite cache
<enebo> more or less removes that penalty from native exts (or even our own core) without having to make an ad-hoc equivalent
<enebo> If it is not rewritten it still runs too just without the caching
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
claudiuinberlin has joined #jruby
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<NightMonkey> Howdy. I'm tracing down apparently hard-coded JVM options in a JRuby + Java Franekenapp setup I inherited, and it *looks* like some are in "jruby-launcher" (-Xss being one). I"m looking for ways to disable any JVM memory-related options sent by jruby-launcher.
<NightMonkey> I guess a basic question is: Can I run a JRuby application without jruby-launcher? (This app is also wrapped with Puma.)
<enebo> NightMonkey: jruby-launcher is largely a gem install. Without the gem it is a bash script
<enebo> NightMonkey: we really only have the launcher for she bang options working from other shell scripts
<enebo> NightMonkey: what I don't know is if you uninstall it do we have a post hook to restore the shell script (if not it is bin/jruby.sh)
akp has quit [Remote host closed the connection]
akp has joined #jruby
<NightMonkey> enebo: Thank you - I see. I looked at the code of jruby-launcher, and see it is "bug-for-bug" compatible with the shell script (including hard-coding JVM memory settings). ;)
<NightMonkey> But, I'm still in "forensic mode" to see how the inherited application startup actually happens. :)
subbu is now known as subbu|lunch
<enebo> NightMonkey: ok so jruby/jruby-launcher is the C++ code and there may be options for overriding some/all of those (but I don't recall). That might also be helpful
<NightMonkey> enebo: Well, I don't know if it is helpful... or I just made more work for a taxed team. :)
<NightMonkey> enebo: But, some sort of flag to just "turn off" hardcoded settings (at least for memory management) might be nice.
<enebo> NightMonkey: yeah probably so. With memory in particular do you want more or less than that default?
<enebo> b
<enebo> that b was not a communication :)
<enebo> you can override those settings at least by doing -J-Xbleh
<enebo> they originally came into being because bundler used to use so much memory and stack during gem resolution we upped to a safe amount. I think bundler is no longer as recursive
<NightMonkey> enebo: I can, but the JVM (AFAICT) will only use it's own internal heuristics if the options are not specified *at all*.
<NightMonkey> s/it's/its/
<NightMonkey> enebo: And there's new shiny heuristics in JVM 8 that I am interested to see in action.
<enebo> NightMonkey: I feel like we did remove one setting for that reason recently but it appears to either only be master (upcoming 9.2.x or I am high)
<NightMonkey> enebo: In other words, if I set them, I apparently *disable* the new JVM dynamic memory tuning.
<enebo> yeah this sounds familar I am going to search our issues a sec
* NightMonkey wishes the JVM internals were less obscure.
<enebo> NightMonkey: not positive this was what I was thinking of but your input on heuristics will probably help put us over the hump
<enebo> NightMonkey: also timely is that 9.2.x will be out aruond of of month (knock on wood) and 9.1.17.0 will be out maybe even sooner.
<enebo> At a minimum we should add an ignore settings if we determine too many people will complain with no settings
<enebo> (new launcher comment is something which I think has been in limbo a while now so not happening soon)
<NightMonkey> enebo: It seems like it might be something that could be deprecated over time, with warnings thrown for those not specifying options over successive versions until the default is changed. :)
<NightMonkey> enebo: I totally agree it would be a negative shock to see your app's memory footprint apparently change when a new jruby-launcher (or jruby release, period), start oom-ing on smaller systems, etc.
<enebo> NightMonkey: well we definitely don't want to force all people to specify options either.
<enebo> MRI doesn't so it would be a perceived negative if we had to. I think until G1 there were no memory ergnomics so what worked before maybe will not work now
<enebo> hey at least we can get it work metaspace settings :)
<NightMonkey> enebo: Yes, but I'm not even clear if G1 is the default. Too much information to sift!
<NightMonkey> And Oracle making half-hidden documentation doesn't help...
<enebo> NightMonkey: Please share your wants on that issue. We will try and come up with something. You mentioning heuristics is an issue we need to deal with
<enebo> It will help make us focus on this near term
<enebo> afk a while
<NightMonkey> enebo: Wow, happy to help! :D
subbu|lunch is now known as subbu
sidx64 has joined #jruby
m4rCsi has quit [Quit: No Ping reply in 180 seconds.]
<headius> G1 is default in 9+
m4rCsi has joined #jruby
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
m4rCsi has quit [Quit: No Ping reply in 180 seconds.]
claudiuinberlin has joined #jruby
m4rCsi has joined #jruby
sidx64_ has joined #jruby
sidx64 has quit [Ping timeout: 265 seconds]
<xardion> NightMonkey: I have a similar application that I wrote (jRuby + Java, uses Puma). I wrote a very simple bash launcher
<xardion> really, it's two. I'll throw up a gist for ya
<xardion> These scripts have some built-in assumptions: a) you're using Gradle with the jruby-gradle-plugin to build an artifact jar, b) that you put these scripts in bin/ in your project root, and c) the project root also has a lib/
<xardion> to use these, you just create appropriately named symlinks to them. The jruby_tools_wrapper.sh is for running gem binaries that you would normally use -C to run (like puma). You just create a symlink to it with a 'j-' prefix in the same dir
<xardion> (feel free to change or even eliminate the prefix, it's just there to prevent namespace collisions)
<xardion> so creating a j-puma symlink would effectively be like running jruby -C puma
<xardion> the other script is for running plain ruby scripts that live in lib/
<xardion> you create your symlinks the same way, but without a prefix
<xardion> so if your "main" script is lib/my_service.rb, you'd make a my_service symlink in bin/ to the jruby_wrapper.sh script.
<xardion> obviously, you probably don't want all my weird JVM options. They're specific to the application, especially the CMS gc one.
<xardion> something wasn't playing nice with the G1 gc, don't remember what
<headius> I do love me some weird JVM options
<GitHub176> [jruby] headius pushed 4 new commits to jruby-9.1: https://git.io/vxbmu
<GitHub176> jruby/jruby-9.1 15898a0 Charles Oliver Nutter: io1 will never be null.
<GitHub176> jruby/jruby-9.1 e263919 Charles Oliver Nutter: Eliminate always-true argument.
<GitHub176> jruby/jruby-9.1 17cde36 Charles Oliver Nutter: Use nonblocking long map and clean up imports.
<NightMonkey> xardion: Wow, thank you!
sidx64 has joined #jruby
sidx64_ has quit [Ping timeout: 276 seconds]
<xardion> they're not THAT weird, it's just: -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+UseCodeCacheFlushing -Djruby.compile.invokedynamic=true
<xardion> I feel like it was the Vertica JDBC driver that didn't play well with the G1GC
<xardion> they probably fixed that in the newer versions and I just didn't bother changing my scripts.
<xardion> It performs just fine with the CMS gc anyway
claudiuinberlin has quit [Quit: Textual IRC Client: www.textualapp.com]
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mfunkmann has joined #jruby
<mfunkmann> Hey folks! I'm quite a jruby noob, so please excuse me if the solutions to my problems seem easy/obvious. I was at least trying to find stuff via Google but wasn't successful. I am using the jrubyfx gem to access the JavaFX GUI classes, but when it comes to the class 'Alert' there don't seem to be any bindings(?) can you suggest me a direction to g
<mfunkmann> o to?
bbrowning is now known as bbrowning_away
mfunkmann has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
mfunkmann has joined #jruby
mfunkmann has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
mfunkmann has joined #jruby
akp has quit [Remote host closed the connection]
mfunkmann has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
akp has joined #jruby
akp has quit [Ping timeout: 268 seconds]
akp has joined #jruby