<headius>
so I ran into a bunch of issues working on kwargs last night
<headius>
my first change was to go back to hash args just being a hash in the args list in IR, but make sure it's directly there (instead of a variable reference) and set the kwargs flag
<headius>
then I discovered that nobody seems to use that flag, and there's logic based on it that started to fire which broke all sorts of stuff
<headius>
specifically, some kinda-hacky logic I think is used for super + **hash
<headius>
like explicitly storing null pairs in Hash as a sigil for **
<headius>
I believe I have specs passing again but I had to modify that logic to additionally only run when there's > 0 pairs
<headius>
anyway, I was hoping you could show me where that kwarg flag is ever set
<headius>
if it's not set I'm not sure this other weird logic is used
<headius>
and good morning :-)
mkristian has quit [Quit: This computer has gone to sleep]
nateberkopec has joined #jruby
pawnbox has joined #jruby
<GitHub197>
[jruby] darrin-wortlehock opened issue #3334: jruby should not depend on bash http://git.io/vZxCK
shellac_ has quit [Ping timeout: 256 seconds]
baroquebobcat has joined #jruby
colinsurprenant has quit [Quit: colinsurprenant]
<GitHub115>
[jruby] eregon pushed 1 new commit to master: http://git.io/vZxlF
<GitHub115>
jruby/master 23b4350 Benoit Daloze: [Truffle] Proper implementation of Kernel#binding and Proc#binding....
baroquebobcat has quit [Ping timeout: 240 seconds]
<lopex>
nirvdrum: I guess, I have it in my links
<lopex>
nirvdrum: I went that unsafe version which turned out to have problems
brauliobo has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
colinsurprenant has joined #jruby
pawnbox has quit [Ping timeout: 246 seconds]
pawnbox has joined #jruby
brauliobo has quit [Ping timeout: 240 seconds]
brauliobo has joined #jruby
nateberkopec has quit [Read error: Connection reset by peer]
Aethenelle has quit [Read error: Connection reset by peer]
<GitHub16>
[jruby] eregon pushed 1 new commit to master: http://git.io/vZxuu
mkristian has quit [Quit: This computer has gone to sleep]
colinsurprenant has quit [Quit: colinsurprenant]
colinsurprenant has joined #jruby
colinsurprenant has quit [Client Quit]
cremes has quit [Ping timeout: 256 seconds]
<GitHub19>
[jruby] mzaccari opened issue #3336: resolv-replace.rb is failing when given an IPv6 address URI http://git.io/vZpBH
cremes has joined #jruby
elia has quit [Quit: Computer has gone to sleep.]
mkristian has joined #jruby
dfr has joined #jruby
bbrowning is now known as bbrowning_away
camlow32_ has joined #jruby
camlow32_ has quit [Remote host closed the connection]
shellac has quit [Ping timeout: 250 seconds]
camlow32_ has joined #jruby
camlow325 has quit [Ping timeout: 250 seconds]
skade has joined #jruby
pitr-ch has quit [Ping timeout: 252 seconds]
brauliobo_ has joined #jruby
brauliobo has quit [Ping timeout: 272 seconds]
subbu is now known as subbu|afk
mkristian_ has joined #jruby
donV has joined #jruby
mkristian has quit [Ping timeout: 255 seconds]
subbu|afk is now known as subbu
donValentin has quit [Ping timeout: 250 seconds]
colinsurprenant has joined #jruby
bbrowning_away is now known as bbrowning
elevy has joined #jruby
<elevy>
howdy. q: http://ci.jruby.org/snapshots/maven/ doesn't seem to exist. what maven repo should one point to to get access to the snapshots?
<elevy>
the Wiki points to that URL as the snapshot repo
colinsurprenant has quit [Quit: colinsurprenant]
colinsurprenant has joined #jruby
nateberkopec has joined #jruby
shellac has joined #jruby
subbu is now known as subbu|lunch
havenwood has joined #jruby
camlow32_ has quit [Remote host closed the connection]
camlow325 has joined #jruby
rsim has quit [Quit: Leaving.]
jensnockert has quit [Remote host closed the connection]
mkristian_ has quit [Quit: This computer has gone to sleep]
havenwood has quit [Ping timeout: 250 seconds]
havenwood has joined #jruby
jensnockert has joined #jruby
jensnockert has quit [Remote host closed the connection]
jensnockert has joined #jruby
jensnockert has quit [Remote host closed the connection]
yfeldblum has joined #jruby
digitalextremist has joined #jruby
jensnockert has joined #jruby
brauliobo_ has quit [Ping timeout: 240 seconds]
jensnockert has quit [Ping timeout: 265 seconds]
mkristian has joined #jruby
havenwood has quit [Ping timeout: 246 seconds]
elevy has left #jruby [#jruby]
tcrawley-away is now known as tcrawley
subbu|lunch is now known as subbu
digitalextremist has quit [Remote host closed the connection]
digitalextremist has joined #jruby
havenwood has joined #jruby
donValentin has joined #jruby
donV has quit [Ping timeout: 246 seconds]
digitalextremist has quit [Read error: Connection reset by peer]
digitalextremist has joined #jruby
pitr-ch has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
havenwood has quit [Ping timeout: 265 seconds]
<GitHub141>
[jruby] nirvdrum commented on commit 8e00e3e: Nice! http://git.io/vZhsD
<GitHub2>
[jruby] eregon pushed 4 new commits to master: http://git.io/vZhs5
<GitHub2>
jruby/master e422866 Benoit Daloze: [Truffle] Do not allow InternalMethod declaringModule to be null.
<GitHub2>
jruby/master 881e24d Benoit Daloze: [Truffle] No InternalMethod null Visibility.
<GitHub2>
jruby/master bc67d03 Benoit Daloze: [Truffle] Global cleanup of dispatch nodes....
<GitHub150>
[jruby] nirvdrum commented on commit eb907ac: Maybe we no longer use them, but I thought there were cases where we needed to provide a different self. We have something similar for the yield helpers. http://git.io/vZhG4
elia has joined #jruby
Aethenelle has quit [Remote host closed the connection]
Aethenelle has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #jruby
skade has quit [Client Quit]
<GitHub58>
[jruby] eregon commented on commit eb907ac: Yeah, calling a block might need to change self (instance_eval) but that's a non-issue as we just create a new frame with the right self. Binding captures the environment at a given point, and its self can only ever be the one that was captured at that point. http://git.io/vZhWE
subbu_ has joined #jruby
subbu_ has quit [Remote host closed the connection]
tcrawley is now known as tcrawley-away
mkristian_ has joined #jruby
elia has quit [Quit: Computer has gone to sleep.]
mkristian has quit [Ping timeout: 246 seconds]
samphippen has joined #jruby
havenwood has joined #jruby
<GitHub80>
[jruby] headius created kwargs-opto (+1 new commit): http://git.io/vZh0s
<GitHub80>
jruby/kwargs-opto ba0df56 Charles Oliver Nutter: First tweaks to make CallInstr know about kwargs structure....
yfeldblum has quit [Ping timeout: 246 seconds]
havenn has joined #jruby
shellac has joined #jruby
mkristian_ has quit [Quit: This computer has gone to sleep]
<headius>
instance variable writes should have a memory fence to guarantee visibility
<colinsurprenant>
this is what I assume too
<headius>
or rather, I would expect it to because I know we have memory fences there
<headius>
should is a little soft :-)
<headius>
maybe I should just say "yes"
<headius>
if it doesn't that's a bug
<colinsurprenant>
oh, ivars writes have an implicit memory fence???
<headius>
yes
<colinsurprenant>
it assumed this was more related to the fact that the ivar init was in the constructor
<headius>
it's a sort of soft guarantee on Java 7 because there's no fence API but it does do a volatile operation after ivar write that should force a fence
<colinsurprenant>
s/it/I
<headius>
not really...right now we don't distinguish constructor from anything else so all ivar writes have a fence
<headius>
we could soften that in constructor and only fence when it's done, but lose guarantees of visibility for threads started within the initialize
<colinsurprenant>
ah, I didn’t know that. does that mean that we don’t need to explicitely memory fence ivars set/get across threads?
<headius>
we'd still need to fence elsewhere because there's no way to specifiy whether you want volitility
<headius>
colinsurprenant: if you mean "we" as in "people writing Ruby code", then yes
<colinsurprenant>
:P
<headius>
note this doesn't mean they're atomic...just ordered
<headius>
if you want atomic you still need something more
<colinsurprenant>
right
<colinsurprenant>
so for example, setting @ivar = true in one thread will be volative and another thread checking for, @ivar value will have the correct memory content, without having to use explict mutex synchronization
<headius>
we haven't wanted to make that an explicit guarantee because we're not sure about the overhead
<headius>
but we've been doing it for a few years now
<headius>
I think they have to be volatile since there's no way to distinguish volatile and non-volatile vars
<colinsurprenant>
and is that true only for Java >= 7 ?
<headius>
we kept hoping someone in ruby-core would see the value of explicit volatility but they're still trying to see the value of parallel threads :-)
<headius>
no, it should be true for Java 6+
<headius>
it's just cheapest in 8
<headius>
6 and 7 use a separate synchronization to force barrier
<headius>
wait no
<headius>
that's only when Unsafe is unavailable
<headius>
if Unsafe is available we use a volatile stamp plus Unsafe.getObjectVolatile
<headius>
if you want to see the code it's StampedVariableAccessor versus SynchronizedVariableAccessor
<headius>
you'll see the check for memory fence API there and fallback to putObjectVolatile
<headius>
we had a user seeing torn writes to ivar table and he worked with JSR166 folks to come up with this
<colinsurprenant>
lemme see … looking
tcrawley-away is now known as tcrawley
<colinsurprenant>
awwww good good I SEE
<headius>
:-D
<headius>
as with all things threading we trust this because nobody's broken it
<headius>
but given JVM memory model it should be right
camlow32_ has joined #jruby
camlow32_ has quit [Read error: Connection reset by peer]
camlow32_ has joined #jruby
lanceball is now known as lance|afk
<colinsurprenant>
headius: thanks the help here!!
camlow325 has quit [Ping timeout: 246 seconds]
camlow32_ has quit [Remote host closed the connection]
<headius>
colinsurprenant: thank you, it is good for me to review this occasionally
yfeldblum has joined #jruby
<headius>
I will muse on updating wiki page...you're the first one to point out that discrepancy
<colinsurprenant>
is the org.jruby.runtime.ivars also used for non instance variables and thus also hold true for the volatility?
<colinsurprenant>
so for all variable assignment? foo = "bar"; Thread.new { if foo == “bar” … }
andrewvc has joined #jruby
<headius>
local vars have no volatility guarantees, no
<andrewvc>
noooooooooooo
<headius>
they're just plain fields in a heap structure
<andrewvc>
sorry @headius, I had long believed that for no real reason
<headius>
normally it won't matter, but in the case of captures it does
<headius>
obviously plain locals are just going to be in one thread's stack anyway
<enebo>
and temps in IR too :)
<andrewvc>
locals are just on the stack? I assumed they had to do something different to deal with closures
<headius>
enebo: heh yeah, but those are only used as JVM locals
<enebo>
the hidden killer
<headius>
andrewvc: captured locals are on heap
<andrewvc>
what's a captured local?
<headius>
noncaptured are on machine stack
<headius>
a = 1; loop { puts a }
<headius>
a is captured by the loop closure
<andrewvc>
ahhhhh
<headius>
no volatility guarantees if that runs across threads
<andrewvc>
so x = 1; Thread.new { x =2 }; puts x is a bad idea then
<headius>
well there's no determinism there to finish the thread, but yes, you have the right idea :-)
<andrewvc>
I mean, could you get a partial write somehow?
<andrewvc>
Assuming determinism doesn't matter
<headius>
more like go = false; Thread.new { do_something; go = true; expect_something_else }; 1 until go; do_something_else
<headius>
in general it should still work fine but we don't make the same volatility guarantees
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<andrewvc>
hmmm, so what's the worst case there?
shellac has quit [Read error: Connection reset by peer]
<headius>
well if we were talking about Java and a non-volatile field "go", the worst case is that it never sees the true
<andrewvc>
ah , got it
<headius>
in practice in JRuby that is unlikely to happen until we can optimize "1 until go" in such a way that JVM could make that "mistake"
<headius>
as it is now "until go" is going to be a memory load plus a volatile call to isTrue
<headius>
er not volatile
<headius>
virtual
<headius>
hotspot won't optimize past that because there's a safepoint involved
<headius>
(I believe)
<andrewvc>
so, would an AtomicReference be the right way to go if you need a volatile local?
<andrewvc>
using the 'concurrent' gem
<headius>
or just an ivar
<andrewvc>
yeah, but I hate leaking state across my classes
<headius>
@go = false
<andrewvc>
I assume the ivar is more performant than AtomicReference too
<headius>
only because there's fewer indirections in the ivar
<headius>
it's just self.get_var essentially
bbrowning is now known as bbrowning_away
<colinsurprenant>
very good info <3
<headius>
it shouldn't be much worse
<headius>
extra object too
<andrewvc>
thanks very much for this info @headius
<headius>
class GoHolder; attr_accessor :go; end; will be about the same as AtomicReference if all you're doing is plain set and plain get
<andrewvc>
mmmm, yeah, I think I'll start using small classes to encapsulate concurrent logic now that I know a bout the ivar stuff
<headius>
which reminds me, we should add lazy set to AtomicReference
brauliobo_ has joined #jruby
<colinsurprenant>
andrewvc: i like the idea (small classes to encapsulate concurrent logic)
<headius>
yeah that would be my recommendation
shellac has joined #jruby
<headius>
and treat AtomicReference as a specialized one-ivar clas s with atomic features
<headius>
in practice it may be faster because it explicitly has only one var and doesn't have to juggle a possibly-growable table
<headius>
would be worth measuring
<headius>
growable ivar table is a PITA for concurrency
<andrewvc>
Interesting, so AtomicReference may be preferable then over small classes
<andrewvc>
that strikes me as leading to more maintainable code anyway
<headius>
yeah we need to do an audit of other variable types and make sure our guarantees still hold
<headius>
I believe our thread locals are volatile since they're visible across threads
<headius>
just realized we don't explicitly call that out on the wiki
brauliobo has joined #jruby
brauliobo_ has quit [Ping timeout: 244 seconds]
<andrewvc>
interesting. hopefully most people aren't trying to read thread locals across threads
<colinsurprenant>
I verified for the threadlocal yesterday or 2 days ago and everything is synchrinized in that code so yes, all access cross memory fence
camlow325 has quit [Remote host closed the connection]
elia has joined #jruby
havenn has quit [Ping timeout: 240 seconds]
Aethenelle has quit [Quit: Aethenelle]
brauliobo has quit [Ping timeout: 255 seconds]
brauliobo_ has joined #jruby
tcrawley is now known as tcrawley-away
<colinsurprenant>
headius: would you like a PR against the wiki for the ivar volatility?
brauliobo_ has quit [Ping timeout: 244 seconds]
brauliobo_ has joined #jruby
enebo has quit [Quit: enebo]
elia has quit [Quit: Computer has gone to sleep.]
pawnbox has quit [Remote host closed the connection]
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
camlow325 has joined #jruby
<brauliobo_>
chrisseaton: I can't build the truffle-head branch
<brauliobo_>
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on project jruby-truffle: Unable to generate classpath: org.apache.maven.artifact.resolver.ArtifactResolutionException: Unable to get dependency information for org.apache.maven.surefire:surefire-junit4:jar:2.15: Failed to retrieve POM for org.apache.maven.surefire:surefire-junit4:jar:2.15: Could not transfer artifact org.apache.maven.surefire:surefire-
<brauliobo_>
junit4:pom:2.15 from/to central (https://repo.maven.apache.org/maven2): java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty