<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
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