<perlun1>
I am seeing a suspected memory leak in my app. An interesting detail is that the MetaClass instances seem to occupy 1 gigabyte (!) of memory. There are also 460 000 MixedModeIRMethod instances, which seem to consume a lot of memory. Any ideas on how to group these by name somehow? I tried with the OQL briefly, but Eclipse Memory Analyzer is not a tool I use every day so I didn't manage to do it yet…
<perlun1>
Is there some way to see from a MetaClass where it was defined? I mean, in what Ruby file.
claudiuinberlin has joined #jruby
shellac has joined #jruby
<perlun1>
This helped: SELECT realClass.cachedName.toString() FROM org.jruby.MetaClass
<perlun1>
I would then export that to a CSV file and it led me in the right direction (helped me see the full class name of the MetaClass instances that were excessively created.)
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vtunka has joined #jruby
claudiuinberlin has joined #jruby
shellac has joined #jruby
claudiuinberlin has quit [Client Quit]
claudiuinberlin has joined #jruby
drbobbeaty has joined #jruby
perlun1 has quit [Quit: Leaving.]
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #jruby
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #jruby
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #jruby
claudiuinberlin has quit [Client Quit]
rdubya has joined #jruby
drbobbeaty has joined #jruby
swills has quit [Ping timeout: 248 seconds]
swills has joined #jruby
swills has joined #jruby
claudiuinberlin has joined #jruby
drbobbeaty has quit [Ping timeout: 240 seconds]
claudiuinberlin has quit [Client Quit]
drbobbeaty has joined #jruby
claudiuinberlin has joined #jruby
headius has joined #jruby
<headius>
howdy howdy howdy
<headius>
got my bouncer back up finally
drbobbeaty has quit [Read error: Connection reset by peer]
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<GitHub128>
jruby/master 46782c4 Charles Oliver Nutter: Add a basic toString to CallSite.
enebo has joined #jruby
<chrisseaton>
headius: hi are you here now?
devilsadvocate has quit [Ping timeout: 246 seconds]
kitallis has joined #jruby
<headius>
chrisseaton: I am
<chrisseaton>
What's the latest information on Java 9 compatibility? I've found some conflicting comments from you (but they're from different points in time so I'm sure things have changed).
<chrisseaton>
For example there's someone above (if your bouncer is off you may not see it) who said he can't compile on Java 9.
<headius>
I made a small tweak on master that lets JRuby build fine on 9 now
<chrisseaton>
And using jnr-posix in TruffleRuby on 9 still gives us a warning about illegal reflective access.
<headius>
I will make it on 9.1 branch but unsure if we're going to do another 9.1.x
<headius>
yep, still plenty of those warnings
<headius>
please feel free to investigate
<chrisseaton>
Are they ever a problem in practice? In our case we're happy with the fallback to that one.
<headius>
I'm not sure which ones you're talking about
<chrisseaton>
We see 'Illegal reflective access by jnr.posix.JavaLibCHelper (file:.../truffleruby.jar) to method sun.nio.ch.SelChImpl.getFD()'
<chrisseaton>
When jnr-posix is initialised.
<headius>
ah, yes...the ones that try to unwrap Java streams
<chrisseaton>
'Please consider reporting this to the maintainers of jnr.posix.JavaLibCHelper'
<headius>
they are a problem in practice if you want subprocess IO using java.lang.Process or stdio on unusual fd's to work properly
<headius>
i.e. if stdio is not on 0,1,2 there's no way to properly get a real fd or channel for wherever they actually are
<headius>
this is the main one I'm concerned about
<headius>
I have a partial patch locally that attempts to do that reflection "the right way" and failover quietly, but it still warns no matter what I do
<chrisseaton>
I think we avoid this problem by always using all native IO.
<headius>
so I think I'm doing something wrong still
<headius>
yes, we don't have that option in many cases, and we don't necessarily control what streams JRuby is given to use
<headius>
also Windows
<chrisseaton>
They've said they're definitely removing all unsupported APIs and replacing - so I don't know why they don't get on and just do it. Like sun.misc.signal - they're only so many ways to do that API so they should just get on do it and I'd switch immediately.
<headius>
that's what I'm going to be pushing on over the next year
<headius>
signal is a good example because you can't route around JVM signal handling
<chrisseaton>
I know they want to get the API right, but come on there's only so many ways to write that.
<headius>
I tweeted a few others like stdio, process IO, raw sockets...none of this requires FFI if they just provide some enhancements to existing APIs
<headius>
enebo: you think we should add a JDK9 label?
<headius>
I'm debating that or just making the Java 8+ label into a JDK Compat label
<headius>
something like that
<headius>
JDK9 bugs are starting to come in unsurprisingly
rdubya has joined #jruby
rdubya has quit [Client Quit]
rdubya has joined #jruby
rdubya has quit [Client Quit]
shellac has quit [Quit: Leaving]
rdubya has joined #jruby
rdubya has quit [Client Quit]
rdubya has joined #jruby
vtunka has quit [Quit: Leaving]
claudiuinberlin has joined #jruby
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #jruby
drbobbeaty has quit [Ping timeout: 258 seconds]
<enebo>
headius: I think java_compat or java9 or whatever names is fine
<enebo>
headius: we don't probably need specific 9 vs 8 vs 7 issues
<enebo>
headius: I am guessing there is not that many but I guess having specific versions is ok as well
<headius>
yeah it's unusual for us to be getting compat issues for JDK X when JDK X + 1 is current
<headius>
so a general "something's up on newer JDK" seems better than label creep
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #jruby
shellac has joined #jruby
subbu is now known as subbu|lunch
drbobbeaty has joined #jruby
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #jruby
<enebo>
kares: assuming I can update appraisal gem on rails-5 is that ok?
<enebo>
kares: It is annoying because it depends on an older rake
<enebo>
kares: for that matter though should we still use appraisal on Rails 5 branches
<headius>
enebo: isn't appraisal only for checking multi-version compatibility?
<headius>
if we are going to reduce or eliminate that, I don't know what purpose it would serve
subbu|lunch is now known as subbu
<enebo>
headius: yeah agreed and it is for that
<enebo>
headius: although I could maybe see value in appraising current point and last or something like that...but I would not bother
rdubya has quit [Ping timeout: 255 seconds]
rdubya has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
<headius>
still wish github had user tags rather than / in addition to project-defined labels
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #jruby
<rdubya>
enebo: +1 for getting rid of appraisal if we can do it, I had a tough time working my way through that when I was first trying to figure out how to run the tests/debug
<rdubya>
I actually had it running with the latest appraisal at one point, so it should be upgradable, but now I just use a modified gemfile so I can bypass it completely
<headius>
I know we don't all agree on this but I'm still pretty convinced that focusing on latest rails is going to be the best use of resources
<headius>
at the very least focusing only on one major at a time
<headius>
at least until we get more community help maintaining legacy support
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<enebo>
rdubya: I did modify it locally and base_test rake task runs but I did not run any appraisals
<enebo>
rdubya: do you use it at all in your tests?
<enebo>
rdubya: or do you use the rails rake tasks which assume it is parallel to you
temporalfox has quit [Read error: Connection reset by peer]
claudiuinberlin has joined #jruby
temporalfox has joined #jruby
<rdubya>
enebo: I use the rake tasks
claudiuinberlin has quit [Client Quit]
<enebo>
rdubya: ah yeah and those appear to just use parallel dir
<enebo>
rdubya: I also did not use appraisals for rails-5
<enebo>
ok well sqlite3 base_test only is 2F/0E
<headius>
awesome
<rdubya>
the postgres adapter is at similar numbers for the arjdbc tests
<rdubya>
still close to 10 failures when running the rails tests
<enebo>
full AR test run
<enebo>
so 5.1 broke a few things but this was not 100% before
<rdubya>
i probably have changes in mine that have fixed some that haven't made it up yet
<rdubya>
i'm testing against 5.0.4 for rails tests
<rdubya>
I wanted to get that solid before going checking against 5.1
<enebo>
trying 5.0.4 for funs
<rdubya>
because we'll need versions that run with each rails version if we want to support rails' suggested upgrade path of going through each major version
<enebo>
so this was not a problem earlier in 5.0.x
<enebo>
and not one in 5.1.x
<rdubya>
that's interesting, that's not an issue I've seen
claudiuinberlin has joined #jruby
<enebo>
rdubya: well the nice thing about the sqlite3 work is the file was an almost identical copy of rails5 source
<enebo>
so in theory I just need to update anything which changed
<enebo>
sqlite3 was much simpler to convert than psql
<rdubya>
some of that has been updated with the recent changes I made
<enebo>
rdubya: nice
<rdubya>
enebo: I've been trying to make sure to run all the sqlite tests along with my postgres tests when making bigger changes so hopefully that is all still working, if you are seeing multiple failures with 5.0.4 then there must be something different environment-wise
<enebo>
rdubya: yeah that was my first thought as well
<enebo>
heh ok it is my installing 5.1.4 in bundler
<enebo>
NameError: Undefined method after_initialize_called for '#<Class:0x21355392>'
<enebo>
ok so it ran about maybe 1/3 of the tests and hit something weird
<enebo>
I am guessing we have a JRuby bug here
<enebo>
it only calls undef if the it finds a defined? method (via two checks)
<rdubya>
interesting, i haven't seen that
<enebo>
appears to make an attr writer in a test but then before it makes it tries to undef anything there already
<enebo>
we must return true to one of the defined? tests but then undef complains that no method exists
<enebo>
It is possible those *_defined? methods are prepend smart or something like that but undef is not
<enebo>
ok this sucks...I put in some puts and it ran to completion now
<enebo>
rdubya: well I checked out that branch but we have not committed since last release
<enebo>
ok ran fine again
<enebo>
hmm if it never fails again maybe it writes tests somewhere
<rdubya>
I have some sqlite test seemingly randomly failing with "[SQLITE_BUSY] The database file is locked (database is locked): SELECT "developers".* FROM "developers" LIMIT ?: ROLLBACK TRANSACTION"
<enebo>
oh yeah
<enebo>
rdubya: I think at some version sqlite switched to multiple files and I think there is some issue which can happen with that
<enebo>
rdubya: or I sort of recall some weirdness with that
shellac has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Puffball_ has quit [Remote host closed the connection]
Puffball has joined #jruby
rdubya has quit [Quit: Leaving.]
<headius>
eregon: that bug is really weird
<headius>
it still loops forever if I preinitialize $go to some value
<headius>
and still sees nil!
<headius>
so it doesn't seem to be a threading thing, more like something wrong with how I'm retrieving it