cpuguy83 has quit [Read error: Connection reset by peer]
shellac has joined #jruby
<GitHub94>
[jruby] chrisseaton commented on commit 6d62f88: Yes I think `-S` could be a good idea. http://git.io/vZujK
cpuguy83 has joined #jruby
elia has quit [Read error: Connection reset by peer]
elia_ has joined #jruby
mdedetrich has quit [Ping timeout: 250 seconds]
mdedetrich has joined #jruby
jruby728 has joined #jruby
<jruby728>
@Headius: I'm not sure what time you have in the US, but it's 14:40 here in Ireland.
iloveitaly has joined #jruby
ninkibah has joined #jruby
havenwood has joined #jruby
jruby728 has quit [Ping timeout: 246 seconds]
* ninkibah
slaps headius around a bit with a large fishbot
<ninkibah>
@headius sorry, I never slapped anybody before in IRC. I'd never do it to you in person. A classmate in college slapped another class mate with a mackerel, and they're now married. Go figure!
rsim has quit [Quit: Leaving.]
erikhatcher has quit [Quit: erikhatcher]
jamo_ has joined #jruby
<headius>
ninkibah: hah, hello there!
<headius>
so 9k takes 50% longer to run your test suite, yes?
<ninkibah>
Hi Headius. What can I do to get those performance figures to you?
vtunka has quit [Quit: Leaving]
<headius>
first of all, are you running with --dev flag to JRuby?
<ninkibah>
Yeah, on my old laptop, our test suite (standard rails 4.2 app) take 600 seconds under 1.7.22, but 880 seconds under jruby 9.0.1.0
<headius>
that turns off some optimizations at JRuby and JVM level to improve startup and cold perf
<ninkibah>
No, I don't use any flags at all. I normally run the tests under RubyMine. It prints out the command line. One moment while I fetch it for you
<headius>
ok, --dev could be a big improvement for both JRuby versions
<GitHub173>
[jruby] enebo pushed 1 new commit to master: http://git.io/vZzV6
<GitHub173>
jruby/master 976c968 Thomas E Enebo: Merge pull request #3319 from jruby/test-findbugs-2...
<enebo>
headius: I guess I got stuck on this idiom of “” + so save columns?
<enebo>
headius: I see enough people accidentally call toString to the point where I see it as a code smell (even though yours is probably the most explicit and direct for that snippet)
<enebo>
headius: ah but I guess String.valueOf works for null
<enebo>
headius: so perhaps toString() is not right there
<headius>
ahh sure
<headius>
null is a thing
<enebo>
I think in little things like this we just do it right without thinking about it anymore
<ninkibah>
headius: The 9.0.1.0 runtime is down 37 seconds to 843 using the --dev flag. But it's still way slower than jruby 1.7.22
<GitHub48>
[jruby-openssl] mkristian opened issue #70: can not use SSL_CERT_FILE to point to java keystore http://git.io/vZzPU
<headius>
ninkibah: ok, so with that flag on we can try to do some sampling... JAVA_OPTS=-Xprof should dump out sampled profiles of all threads that run
<ninkibah>
Just spotted my JRUBY_OPTS in my command line are: JRUBY_OPTS=-J-Xmx2000m --dev -Xcompile.invokedynamic=false -J-XX:+TieredCompilation -J-XX:TieredStopAtLevel=1 -J-noverify -Xcompile.mode=OFF
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
brightball has joined #jruby
donV has joined #jruby
pawnbox has joined #jruby
mdedetrich has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<ninkibah>
headius: I created a gist of the output, however, I got bored waiting for it to continue after emitting the first set of stats, and then I went on the rampage with ^C and ^\. https://gist.github.com/ninkibah/e4d71ddfed8edaf6a951
digitalextremist has joined #jruby
<ninkibah>
headius: I'm going to try running just one class and getting profiling for it.
<headius>
ninkibah: ok
<enebo>
Hmmm
<headius>
wow, Object.clone? that's weird
<enebo>
ninkibah: This may not change speed but you can add -Xjit.threshold=-1. I can see this if performcing full builds in interp mode
<enebo>
ninkibah: that happens off thread but it is clouding this instrumented profile
<headius>
45,6% 0 + 17253 java.lang.Object.clone
<headius>
that's main thread samples
<enebo>
you talkingto me?
<enebo>
headius: though this is showing up less it still stands out to me: 0,9% 0 + 354 java.lang.Throwable.getStackTraceElement
<headius>
yeah
<enebo>
something is throwing
rsim has quit [Quit: Leaving.]
<enebo>
man if we are doing something dumb with the Object.clone it would make my month
<headius>
I don't see anything that looks weird in codebase
<enebo>
JDBC, FFI, and Zip in play…lots of library action which may be doing it too
<headius>
the only clone uses that would be different from 1.7 are in IR
<headius>
that clone is a weird one to see at the top
<headius>
ninkibah: a new flag for you (remove -Xprof): -Xrunhprof:depth=20
<headius>
it will be incredibly slow, so just run that same one thing
<headius>
let it chew and it will spit out a giant java.xprof.txt file (I think that's the filename)
<headius>
zip it up and email to me at headius@headius.com (probably too big for gist to take it)
bb010g has joined #jruby
<headius>
it's an allocation trace, it will show where all objects are getting allocated...I should be able to see why clone is getting hit so hard then
<headius>
it could be a sampling artifact but then I'd expect to see it in 1.7.22 too
<ninkibah>
headius: OK will do. Do you want the 1.7.22 as well, or is it ok just to run it for 9.0.1.0?
<chrisseaton>
^ Truffle even makes things like objspace easy to implement with high performance (until you actually start tracing allocations that is I'll admit)
elia has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
<GitHub37>
[jruby-openssl] kares commented on commit af83d3a: could we do this backwards compatibly - seems like no biggie ... won't exists on **1.7.4** ? http://git.io/vZ24z
pitr-ch has joined #jruby
colinsurprenant has joined #jruby
<GitHub92>
[jruby] pitr-ch commented on commit 6d62f88: Ok, the resulting functionality is close enough. In most cases it'll do the same thing (it does not use PATH). Renaming. http://git.io/vZ2KG
<colinsurprenant>
hey!
<colinsurprenant>
got a question on thread local storage....
<colinsurprenant>
is setting thread-local vars from another thread, thread-safe? ie @thead[:foo] = :bar … is there an implicit memory barrier with this construct or we should use an explicit mutex?!
<colinsurprenant>
(generally in Ruby and specifically in JRuby?)
bb010g has quit [Quit: Connection closed for inactivity]
<lopex>
colinsurprenant: afaik on ruby side it's fine by definition since mri controlls thread stacks
<lopex>
colinsurprenant: but on jruby side it depends on the usage
<lopex>
if @thead is prone to races then I guess it might brake
<lopex>
colinsurprenant: ruby still doesnt have proper memory model
<lopex>
tarcieri: what's the current state of that ?
<colinsurprenant>
thanks lopex … I guess this will require some investigation :P
<lopex>
colinsurprenant: just hang out here on the channel here
<colinsurprenant>
AFAICT, looking at JRuby source, the RubyThread class defines private transient Map<IRubyObject, IRubyObject> threadLocalVariables; and nothing crosses a memory barrier when getting/setting these
<colinsurprenant>
why is that maked transient ?? was that confused with volatile ?!?!?
enebo has quit [Quit: enebo]
<lopex>
colinsurprenant: transient is just a serializability, volatile is about barriers
<colinsurprenant>
that’s why I’m saying that transcient is really weird here
<lopex>
that one is fully synchronized so I guess no problem here
<lopex>
but @ might be the problem
<colinsurprenant>
it should be volatile no?
<colinsurprenant>
oh?
<lopex>
in java fields are volatile - the define the barriers
<lopex>
synchronized keyword is fully locked semantics
<lopex>
volatile means - no reorder can happen with another read
<lopex>
so you get a barrier
<colinsurprenant>
oh actually, in master its “volatile transient” but in 1.7 branch I have checked out it’s just “transient”
<lopex>
dont bother with the transient modfier
<colinsurprenant>
yes, I know that, this is why found strage the lacking of the volatile on that hashmap, and why use transcient when there but I don’t see the synchronize,
<colinsurprenant>
oups
<colinsurprenant>
and why use transcient when there’s nothing about serialization around that
<colinsurprenant>
I did not see the synchronize? where? (looking ...)
<lopex>
because the class can be serialized - and you dont wonat that file being included
<lopex>
volatile means - it cannot be reordered, but stil be carefull
<colinsurprenant>
right
<colinsurprenant>
but its syncronized so we are golden
<colinsurprenant>
all good
<lopex>
well, like barriers
<lopex>
colinsurprenant: well, @ implies ivar lookups
<lopex>
colinsurprenant: so you would have to reassure that as well
<lopex>
@ is evil
pitr-ch has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<colinsurprenant>
in my example I had a @thread to make it obvious I was talking about referencing a “foreighn” thread through a variable
<colinsurprenant>
instead of Thread.current[:foo] for example
<lopex>
colinsurprenant: @ is an ivar lookup
<colinsurprenant>
yes
<lopex>
so a = @x is not atomic
<colinsurprenant>
true
<lopex>
colinsurprenant: on that one, I recommend asking someone more competent
<colinsurprenant>
but this is not the problem here:
erikhatcher has joined #jruby
<colinsurprenant>
@t = Thread.new { … }
<lopex>
so @foo is no a race candidate ?
<colinsurprenant>
@t[:foo] = :bar
<lopex>
colinsurprenant: oh sure, then it all goes to that #[]
<lopex>
if it's save thant it's save
<lopex>
right ?
<colinsurprenant>
I wanted to know if from within that thread, will Thread.current[:foo] be correctly visibile
<colinsurprenant>
so will @t[:foo] = :bar will have a memory barrier? - answer is yes since the getThreadLocals method is synchronized (which I missed when looking)
<colinsurprenant>
thanks for pointing it out :)
<lopex>
did I ? :)
<mjc_>
is there a document somewhere that describes how symbols are implemented in JRuby?
<mjc_>
hah I was hoping to find something I can show a junior
<AntKnee>
who you calling Jr
<lopex>
colinsurprenant: it seems that from op_aref in RubyThread everytinhg is synced
<colinsurprenant>
lopex: ah true … public synchronized IRubyObject op_aref(IRubyObject key)
<lopex>
colinsurprenant: in that case you're golden
<lopex>
colinsurprenant: my concern was mostly that ivar access
<colinsurprenant>
yup! thanks!
<lopex>
colinsurprenant: since I dont know if you're oging to change that
<lopex>
*going
ninkibah has quit [Ping timeout: 246 seconds]
<lopex>
that would be a problem
<lopex>
mjc_: well RubySymbol is the place to go but I can help
<lopex>
mjc_: basically it's just an api around a map from java String -> rubySymbol afair
<lopex>
might have changed nowadays
bbrowning is now known as bbrowning_away
shellac has quit [Quit: Computer has gone to sleep.]
lanceball is now known as lance|afk
iloveitaly has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
yfeldblum has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
erikhatcher has quit [Quit: erikhatcher]
cprice404 has quit [Quit: Konversation terminated!]
knu has quit [Read error: Connection reset by peer]
cprice404 has joined #jruby
shellac has joined #jruby
knu has joined #jruby
cprice404 has quit [Quit: Konversation terminated!]
jeremyevans has joined #jruby
tcrawley-away is now known as tcrawley
phrinx has quit [Quit: Leaving...]
<chrisseaton>
lopex: zero impact until you start tracing, and then it keeps references to more objects for the trace, but that's what you'd expect
phrinx has joined #jruby
cprice404 has joined #jruby
phrinx_ has joined #jruby
havenwood has quit [Ping timeout: 244 seconds]
phrinx has quit [Ping timeout: 256 seconds]
<lopex>
chrisseaton: wow
<lopex>
chrisseaton: and it's truflle runtime that does all of the work ?
<lopex>
astonishing about the depots
<chrisseaton>
yes we have two versions of the code to allocate and object, and truffle makes it very easy to switch between the two, and with no cost to check if you need to do that
<chrisseaton>
allocate *an* object, I mean
<lopex>
chrisseaton: astonishing
<chrisseaton>
there's no specs for this stuff at the moment though so hard to check it's all correct
<lopex>
chrisseaton: I guess the feeling like you said about the constant folds
<lopex>
and deopt
tcrawley is now known as tcrawley-away
<lopex>
chrisseaton: so js would equally benefit from that
<lopex>
chrisseaton: trying to fit my mind on v8 somewhere
<chrisseaton>
if you had a JS language feature that allowed you to trace allocations, yeah it could do the same thing. Same in R, Python, C, etc
<lopex>
chrisseaton: amazing
<lopex>
well I guess I can somewhat imagine the thing, still amazing
<lopex>
chrisseaton: I'm very happy so huge resources are being put from Oracle
<chrisseaton>
thanks - I think Oracle probably put more money that anyone else into Ruby implementation work, and it's nice to see that noticed
<lopex>
chrisseaton: yeah I can see that
<lopex>
chrisseaton: but I'm biased :)
mje113 has quit [Quit: Connection closed for inactivity]
<lopex>
chrisseaton: I guess I have been born too early
<tarcieri>
lopex: of what, the Ruby memory model?
<tarcieri>
what Ruby memory model? ;)
<lopex>
tarcieri: @ semantics
<lopex>
chrisseaton: you're being scared by that too ?
<lopex>
AA is one thing
<lopex>
but no barriers are defined for them
<chrisseaton>
Petr Chalupa is looking at a memory model, and eregon recently removed our GIL
<lopex>
chrisseaton: wrt @ ?
<chrisseaton>
sorry don't understand that?
<lopex>
it can be optimized given a model
<chrisseaton>
instance variables?
<lopex>
chrisseaton: ivars
<lopex>
yes
<chrisseaton>
well in some ways we're better off without a memory model as we can optimise however we want
<lopex>
chrisseaton: so go ful AA ?
<lopex>
*full
<chrisseaton>
if we have just one rule - no serialisation except if you do a synchronisation event, then that's also very good for optimisations, and that's what we, JRuby and Rubinius do at the moment really
<lopex>
hm
<chrisseaton>
I think that's a very reasonable memory model, but I think Petr favour some kind of guarantee that all ivars set in a constructor will be visible when the object becomes visible
<chrisseaton>
and that does seem to be how uninformed Ruby programmers expect things to work
<lopex>
well, I'm not an expert on thins, but ivars was always an issue
<chrisseaton>
lopex: IMHO the bottom line is don't access shared state with synchronisation - anything else is crazy
<chrisseaton>
without synch I mean
<lopex>
sure
<lopex>
right
<chrisseaton>
I was talking to one Ruby-famous person recently - I won't name him - and he was trying all these things to somehow publish an object without any synch thinking he could beat the system - but everything he tried had a subtle flaw that was hard to even understand without lots of expect knowledge
<chrisseaton>
double-checked locking is the classic example of this kind of thinking
<chrisseaton>
there's something quite Faustian about it
<lopex>
concurrency is hard
<lopex>
and that mutable ruby is making it harder
<chrisseaton>
I think most industrial programmers do not have any idea that writes by one thread can appear out of order from another
shellac has quit [Quit: Computer has gone to sleep.]
<chrisseaton>
And it's easy to see why - it's so completely at odds with the rest of their understanding of computation
<lopex>
chrisseaton: the world will en up with frp with it's proper defintion
<chrisseaton>
I'd favour dataflow, which is what I started writing my PhD about, but it's probably two-sides of the same coin
<lopex>
chrisseaton: elm is a one answer
<lopex>
chrisseaton: what's your stand on pure fp ?
<chrisseaton>
I think sometimes you need shared state to get tractable operational complexity
<chrisseaton>
I have a pet benchmark called 'lee routing' that I think shows this well - and I'm doing a demo of it in Ruby at the moment so I'll show it soon
<lopex>
I guess I agreee
<lopex>
chrisseaton: but otoh you can optimize pure fp onto madness shared ops
<lopex>
are we still in the swamps ?
<chrisseaton>
yes, but we're kind of getting into magic compiler territory there
<chrisseaton>
theoretically a compiler could transform a concurrent pure FP program into shared state, but in practice it cannot
<lopex>
chrisseaton: we get a couple of camps, like ultra statically checked etc
<lopex>
like haskell
<lopex>
chrisseaton: hmm, but I heard an ocaml program using lenses can transform it into a struct updates
<lopex>
chrisseaton: well, that's subproblem you described
<chrisseaton>
does the ocaml solution work in a concurrent environment though? I thought it was just sequentially
<lopex>
chrisseaton: but ultimately we need some validity
<lopex>
chrisseaton: I dont know
<lopex>
chrisseaton: anyways, it all bils down to the lambda cube again - as I cam see it
<lopex>
you have a verivfication at some point or you dont
dbussink has quit [Ping timeout: 252 seconds]
jeregrine has quit [Ping timeout: 252 seconds]
<lopex>
chrisseaton: oh, have you seen the mars curiosity software dev jpl video ?