<jmalves>
Hey all! Is there a way to do the equivalent of `synchronized (object) { }` in ruby?
drbobbeaty has joined #jruby
ur5us has quit [Ping timeout: 260 seconds]
nirvdrum has quit [Remote host closed the connection]
nirvdrum has joined #jruby
<rg[m]>
jmalves: Mutex class? it has a synchronize method
jmalves has quit [Remote host closed the connection]
nirvdrum has quit [Remote host closed the connection]
nirvdrum has joined #jruby
jmalves has joined #jruby
jmalves has quit [Ping timeout: 265 seconds]
subbu is now known as subbu|away
subbu|away is now known as subbu
<JasonRogers[m]>
I have what may seem like a stupid question. I'm using parslet (http://kschiess.github.io/parslet/) to parse our custom query language. In MRI, I have to set the VM's stack size to ~2MB in order to parse our longest expression. But, in JRuby I have to set `-Xss23m` in order to avoid a `Java::JavaLang::StackOverflowError`. That won't be a tenable setting when pushing this to production since the server can easily use up
<JasonRogers[m]>
to 150 threads for different Puma requests, the Sequel connection pool, and my app's own processing needs. Is there a way to compile the code for all my included gems to native Java in order to reduce the stack? Would that even work if there is a way to do it? Or am I barking up the wrong tree altogether, and should just reimplement all of the parsing and transformation using a native Java lib that is not recursive?
sagax has quit [Ping timeout: 256 seconds]
jmalves has joined #jruby
jmalves has quit [Ping timeout: 256 seconds]
<enebo[m]>
dave.g: so it witin a define_method defined method?
<enebo[m]>
dave.g: that particular bug is very particular to define_method as it converts it from a closure into a real method (when it can)
<enebo[m]>
So the cause of that bug only happened as a result of that conversion
<enebo[m]>
generally that fell through bug it from two things: 1) some bug we did not anticipate with non-local flow control 2) we do not properly synchronize during compilation and some blocks within a method (or another block) executes after the method has been changed
<enebo[m]>
We feel we had both 1 and 2 solved so ...
<enebo[m]>
dave.g: if you persistently get the error in Puma that is interesting as well since this is generally about in flight promotion of code from our interpreter to becoming compiled code
<enebo[m]>
dave.g: another idea would be to run with same puma config but disable the JIT (note: this will substantially affect performance). If it still happens then it is not #2 above
<enebo[m]>
JRUBY_OPTS=--dev
<enebo[m]>
actually even better: JRUBY_OPTS=--dev -Xcompile.jit.threshold=-1
<enebo[m]>
dave.g: yeah I am only suggesting as a debugging activity but I guess you need something hitting it like a real load
<enebo[m]>
dave.g: and depending on how much it slows it could even cover up the issue and not happen which would not allow us to say it is not #1 if it never happens