<krainboltgreene>
Ahhh. Okay, done, I can do simple.
<headius[m]>
It is a bit old... "As of late September 2007"
<krainboltgreene>
Ahahaha
<headius[m]>
"the JRuby compiler is considered complete"
<headius[m]>
Why do I write things like that
<krainboltgreene>
So far jruby has been a dream. The only thing that truly surprised me was the whole "J-Xmn is default 500 and will use all of it".
djellemah has quit [Client Quit]
<headius[m]>
That should be open-ended in recent JRuby versions and just delegate to the JVM to use however much it wants
<headius[m]>
And then you can throttle it through -Xmx
<headius[m]>
We removed all our memory flags for 9k I think
<headius[m]>
JVM has some heuristic like 1/2 physical memory something
<krainboltgreene>
Oh really? So if I have a memory cap of 124MB, I want to set -J-Xmx500m?
<headius[m]>
124MB?
<krainboltgreene>
Cloud Run container constraint.
<headius[m]>
With cloud run I'm not sure
<krainboltgreene>
It's just how much I'm allowed to allocate to a container, so for example, my current container needs are set to 512mb because jruby is allocating 500 for the heap.
<headius[m]>
124 heap is doable for small services but it would be tight
<headius[m]>
Ah well you can try throttling it on your system and see if it reaches a tipping point or you get to a comfortable size
<headius[m]>
You can also hook up one of the JVM monitoring tools and see how much memory a GC'ed heap actually has in use and go from there
<headius[m]>
I will have a look at cloud run a but
<headius[m]>
But
<headius[m]>
Ugh bit
<krainboltgreene>
It's really looking good. Shove whatever you want in a container, as long as it reads from port 8080. You tell Cloud Run "Hey, this image can handle a concurrency of X before you should give me more containers." and boom.
<headius[m]>
Is cloud run basically just a knative front end to Google cloud then?
<krainboltgreene>
Yes.
<krainboltgreene>
I would actually call it "Hosted knative and a special UI"
<krainboltgreene>
Because you can point the UI to any knative on any kubernetes.
<headius[m]>
Hey I understood a thing
<headius[m]>
Ok
<headius[m]>
I feel like I'm missing some docs but I'm on mobile at the moment...in any case it will basically come down to how much memory you can give it and how little the JRuby app can get by with
<krainboltgreene>
I'm going to play with some values. Luckily the dev cycle on this project is very fast.
<headius[m]>
👍
<krainboltgreene>
I wonder, would jruby/java bark at me if I exceed -J-XX:MaxRAM=256m?
<headius[m]>
Unclear from the cloud docs
<headius[m]>
It may kill it as a runaway instance
<headius[m]>
Without warning
<krainboltgreene>
Cloud Run will definitely terminate with a "You used too much memory".
<krainboltgreene>
I was wondering if jruby/java will.
<headius[m]>
The JVM will raise OutOfMemoryError if the app exceeds max heap
<krainboltgreene>
Muahaha, I was able to induce it. You called it headius[m], 120~ is very much just about the limit.
<krainboltgreene>
In fact, I think I'm going to have to go with the 256m container size. I wonder how much puma is eating.
rusk has joined #jruby
drbobbeaty has quit [Ping timeout: 250 seconds]
shellac has joined #jruby
drbobbeaty has joined #jruby
krainboltgreene has quit [Quit: Connection closed for inactivity]
shellac has quit [Quit: Computer has gone to sleep.]
shellac has joined #jruby
rusk has quit [Remote host closed the connection]
xardion has quit [Remote host closed the connection]
<jeremyevans>
probably not a bug, but I'm not sure whether this is expected: on Java 8, A::B and A.B both work if B is a Java constant and not a method, but on Java 11, only A::B works, not A.B (NoMethodError raised for A.B).
<lopex>
diff between 8 and 11 is definitely not expected
<lopex>
might be some invoke dynamic thingie
<lopex>
jeremyevans: what jvm's your're testing on wrt sequel etc ?
<lopex>
but the thing you;re seeing might be re lated to invoke dynamic
<jeremyevans>
lopex: Java 8: jruby 9.2.7.0 (2.5.3) 2019-04-09 8a269e3 OpenJDK 64-Bit Server VM 25.202-b08 on 1.8.0_202-b08 +jit [OpenBSD-x86_64]
<jeremyevans>
lopex: Java 11: jruby 9.2.7.0 (2.5.3) 2019-04-09 8a269e3 OpenJDK 64-Bit Server VM 11.0.3+7-1 on 11.0.3+7-1 +jit [OpenBSD-x86_64]
<lopex>
yeah, seems to be quite deep
<lopex>
jeremyevans: poke headius[m] on that
<jeremyevans>
lopex: These are both using OpenBSD's Java 8 and 11 ports. I'm testing a switch from Java 8 to 11 for OpenBSD's JRuby port. No issues except for this one.
<jeremyevans>
headius[m]: The particular constant is java.sql.Statement.RETURN_GENERATED_KEYS
<lopex>
I'd opt for 11 changes since constant caches rely a lot on invoke dynamic
<jeremyevans>
lopex: Yep, that's what I get. So it doesn't look OpenBSD specific
<jeremyevans>
lopex: does this work?: jruby -e "p java.sql.Statement::RETURN_GENERATED_KEYS"
<lopex>
java version "11" 2018-09-25
<lopex>
trying
<lopex>
jeremyevans: 1
<jeremyevans>
lopex: Yep. So same behavior in OpenBSD and Linux
<jeremyevans>
lopex: Should I file a bug for this? After all, accessing a constant in ruby via A.B does not work either, so I would not expect it to work for Java constants
<jeremyevans>
lopex: This could be considered an unintentional bug fix :)
<lopex>
jeremyevans: yeah, I guess so
<lopex>
it seems to boil down to constant lookup
<jeremyevans>
lopex: Issue 5730 submitted for this (I guess the IRC GitHub notifications are no longer on?)
<lopex>
jeremyevans: yeah, wrt GH bots, I think headius[m] and enebo[m] are triing some matrix thingies
<lopex>
jeremyevans: here now, are users from gitter and matrix
<lopex>
and gitter is via matrix bridge
<lopex>
jeremyevans: strange times
<jeremyevans>
lopex: I'm guessing it went away when GitHub turned off IRC notifications, telling people to replace them with web hooks. I know I had to write a web hook handler for the IRC channels I have related to my projects (open source if anyone wants to use it)
<lopex>
yeah, thats why the matrix goes in I think
<lopex>
I personally have no opinion, I'll go with the thing that will catch up