nirvdrum has quit [Read error: Connection timed out]
nirvdrum has joined #jruby
lucasb has quit [Quit: Connection closed for inactivity]
nirvdrum has quit [Ping timeout: 240 seconds]
Antiarc_ has quit [Ping timeout: 276 seconds]
Antiarc has joined #jruby
Antiarc has quit [Read error: Connection reset by peer]
Antiarc has joined #jruby
Antiarc has quit [Ping timeout: 240 seconds]
Antiarc has joined #jruby
Antiarc has quit [Quit: ZNC 1.7.2+deb2ubuntu0.1 - https://znc.in]
Antiarc has joined #jruby
drbobbeaty has quit [Ping timeout: 250 seconds]
shellac has joined #jruby
sagax has quit [Ping timeout: 245 seconds]
drbobbeaty has joined #jruby
sagax has joined #jruby
_whitelogger has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
shellac has joined #jruby
nirvdrum has joined #jruby
lucasb has joined #jruby
<rdubya[m]>
enebo: kares I think I have the mssql gem in a good place, I created a placeholder PR and assigned both of you as reviewers, right now the travis build is failing because 50.5 hasn't been set up in the arjdbc 50-stable branch but I think once that happens we should be good
shellac has quit [Quit: Computer has gone to sleep.]
<kares[m]>
nice!
<kares[m]>
enebo: nice on the cast issue repro - wanted to try smt simple as well!
<kares[m]>
wonder if there's another way, now that we reproduce, avoiding the lock ...
<kares[m]>
JRuby could use a test target (optional) to test code like that (with 'real' gems)
shellac has joined #jruby
<enebo[m]>
kares: I do wonder how big a deal this really is? I meam how many types actually exist in any ordinary app
<enebo[m]>
kares: 20,000 types during startup having a synch block should not be a huge impact and many get loaded before thread listening stuff tends to happen
<enebo[m]>
kares: Trying to think of something more esoteric like constantly making new types (ala DCI pattern)
<enebo[m]>
although that pattern is already slow as hell
<enebo[m]>
kares: what was the issue with lock contention in AR you found and fixed recently?
xardion has quit [Remote host closed the connection]
rusk` has quit [Remote host closed the connection]
xardion has joined #jruby
shellac has quit [Ping timeout: 240 seconds]
<kares[m]>
okay, that logic makes sense ... just a bit precautious after seeing some sync issues
<kares[m]>
that fix was on (singleton) class generation at runtime (due `obj.clone`)
<kares[m]>
did not consider type stability since the report seemed like the cast exception (ivar shape generation) happened under load some time into running sidekiq
<enebo[m]>
kares: I believe this is only happening because the threads happen to be loading the class at the same time so it is only happening at the beginning....BUT...the error may take longer to blow up because not all those ivars may be hit until later while it is running
<enebo[m]>
but I am mildly worried there is some usecase with lots of loaded classes ... OTOH those use cases would never do well for any impl
<headius[m]>
enebo: kares so we are ok with the synchronization then
<kares[m]>
fine by me
<headius[m]>
like I mention in the PR this will eventually be moot once individual objects can have different shapes, but I don't have a timeline for implementing that
<enebo>
headius[m]: yeah my only comment is really about impact of continuous class creation (which maybe is some form of singleton) but I doubt those would do well anyways
<enebo>
headius[m]: but my overall analysis is most types load before threads fire up and number of types overall is relatively small compared to objects made from them
<enebo>
seems like at most it could have a very small impact on startup
<headius[m]>
shouldn't affect singletons...the variable layout is calculated and stored on the nearest real class
<enebo>
ok so much the better then
<headius[m]>
and singletons are already constructed by the time they become singleton
<headius[m]>
so it should be fine
<enebo>
ah yeah that makes sense
<headius[m]>
I'll merge in the PR then
<enebo>
so then the only case would be some weird thing where people continuously make classes/modules and I feel that is pretty out of scope as a worry
<enebo>
yeah you saw my repro script?
<headius[m]>
yeah
<headius[m]>
my confusion at this point is how two threads would come to different conclusions about the shape of the object
<headius[m]>
it's just walking the same set of classes and methods
<enebo>
headius[m]: yeah that I don't get either...but I did see 6/7 and 4/7 on shapes too
<headius[m]>
maybe we can get this repro to work without this library
<enebo>
headius[m]: so whatever that race is perhaps is setting some state on an intermediate object so next thing skips it
<enebo>
we walk down to object and mark each object as done or something?
<headius[m]>
hmm
<enebo>
I thought there was something marked but I don't see it in the before version either
<headius[m]>
right
<headius[m]>
there's nothing marked for this
<headius[m]>
we did sort of mark for the old become_java reification but that's not related to this code
<headius[m]>
e.g. it reified from the top down
<enebo>
if (cls instanceof RubyClass) {
<enebo>
cls = ((RubyClass)cls).getSuperClass();
<enebo>
oh cls!=null is around that
<enebo>
I was trying to decipher how nested modules worked
<enebo>
this is original discoverInstanceVariables
<headius[m]>
yeah
<enebo>
Yeah I would definitely like to understand why now
<enebo>
I mean sync'ing definitely is a valid fix for 9.2.9 if we do not shed more light but this is a pretty weird issue
<headius[m]>
it doesn't seem like it should happen, does it
<enebo>
Well if you think about ways modules can be included I could see some races
<enebo>
like self.included doing include/extend
<enebo>
or something like that
<headius[m]>
yeah if they were being included later
<enebo>
but concurrently both doing that
<headius[m]>
but this case doesn't seem to do that
<enebo>
but I do not see that here
<enebo>
so perhaps that scenario does justify the sync regardless but I still want to know why this case is broken
<enebo>
It is down to a new on one class in that library
<enebo>
Also I noted that execution speed of instrs themselves helps the race if it executes slower
<enebo>
That does point more towards an 'self.included' sort of race
<headius[m]>
so regarding the overhead of the sync...it will probably be lower than the overhead of generating the class twice, which would have been happening sometimes under contention before
<headius[m]>
yeah I just don't see any weirdness in these types in that http-cookie library
<enebo>
yeah if it is actually happening much
<enebo>
yeah I guess if we can think of a case like dynamic include it means we have to have a sync or accept some double creation with checks sort of soln
<headius[m]>
there's an inherited hook but it doesn't do anything to the types