<kares[m]> <lopex[m]1> "I'm using this too" <- are you? I haven't but when I saw it I thought it was cool (but than my java xml knowledge is outdated)
drbobbeaty has joined #jruby
nilsding has joined #jruby
<headius> Good morning!
<CrisShupp[m]> Does mkristian lurk here? I opened this issue https://github.com/torquebox/jruby9-maven-plugins/issues/5 on the jruby9-exec-maven-plugin
<headius> I don't think so unfortunately. I have been planning to take over most of his JRuby-related projects to help take the load off
<CrisShupp[m]> Should this bug be written up on the JRuby issue tracker?
<headius> ahh yes this issue
<headius> I think this might have been filed in another form elsewhere
<headius> huh
<headius> ractor code uses ko1's new C expression language in Ruby
<headius> enebo: ^
NoraHoward[m] has quit [Ping timeout: 246 seconds]
NoraHoward[m] has joined #jruby
drbobbeaty has quit [Ping timeout: 252 seconds]
UweKuboschGitter has quit [Ping timeout: 246 seconds]
UweKuboschGitter has joined #jruby
Bi[m] has quit [Ping timeout: 246 seconds]
ahorek[m] has quit [Ping timeout: 250 seconds]
Bi[m] has joined #jruby
ahorek[m] has joined #jruby
Bi[m] has quit [Ping timeout: 268 seconds]
Bi[m] has joined #jruby
JesseChavezGitte has quit [Ping timeout: 264 seconds]
JesseChavezGitte has joined #jruby
RomainManni-Buca has quit [Ping timeout: 264 seconds]
RomainManni-Buca has joined #jruby
rebelwarrior[m] has quit [Ping timeout: 268 seconds]
shibz[m]1 has quit [Ping timeout: 246 seconds]
rebelwarrior[m] has joined #jruby
shibz[m]1 has joined #jruby
rebelwarrior[m] has quit [Ping timeout: 250 seconds]
rebelwarrior[m] has joined #jruby
KarolBucekGitter has quit [Ping timeout: 268 seconds]
KarolBucekGitter has joined #jruby
CharlesOliverNut has quit [Ping timeout: 264 seconds]
CharlesOliverNut has joined #jruby
lopex[m]1 has quit [Ping timeout: 264 seconds]
lopex[m]1 has joined #jruby
<enebo[m]1> hahah
fzakaria[m] has quit [Ping timeout: 250 seconds]
fzakaria[m] has joined #jruby
BlaneDabneyGitte has quit [Ping timeout: 268 seconds]
BlaneDabneyGitte has joined #jruby
<headius> I have started filling in the blanks for Ractor
<headius> It is pretty much an actor API but the isolation characteristics are still not clear to me. I think the most straightforward way to handle it would be to spin up a second jruby instance and marshall or otherwise transfer values across
<headius> I'm not exactly sure how that's supposed to work with class definitions and patches and libraries because it sounds like the classes are supposed to be visible across ractors
<headius> Which to me says they are still a massive hole in this isolation
<enebo[m]1> headius: my understanding is classes must be loaded similarly in each ractor. I do not think class sharing exists the last time I saw a talk on it
<enebo[m]1> I also thought there was severe limitations on what could be shared
<enebo[m]1> I should probably look at modern docs though
<headius> Ok that would be far better and trivially implementable with two JRuby instances
<headius> In that case, if this becomes a popular api, we may look into options for sharing more between runtimes to reduce their size
<enebo[m]1> well it does claim classes/modules are shared but then says data must be immutable
<headius> Which could include things like IR and statically optimized jitted code that would be the same everywhere
<headius> Yeah see that is what I read
<headius> This half-isolation will be much more tricky to implement
<enebo[m]1> but does that means the classes must be frozen?
<enebo[m]1> If we know it cannot change then we really need to know what state can change
<headius> If they're not doesn't that mean one ractor could screw up the methods in a different ractor
<enebo[m]1> yeah you would think so
<headius> I think this is always been the big open question for us and it seems like they just punted
<headius> If the classes were isolated then we essentially have MVM and the implementation side on jruby would be trivial
<enebo[m]1> oh wow it supports move semantics on unshareable objects
drbobbeaty_ has joined #jruby
<enebo[m]1> That will just be marshal at some level
<enebo[m]1> First pass could literally be marshal
<headius> Yeah, worst case we would marshall the frozen guts to a new object but possibly could reattach an object to a different runtime
<headius> Reattaching the object worries me because the old container is not supposed to be able to access it anymore. I have no idea how they enforce that on the heat given that there could be thousands of references to it
<headius> Heap not heat
<enebo[m]1> heat
<headius> It all seems very loosey-goosey in any case
<enebo[m]1> yeah I feel the same way
<enebo[m]1> and the I_CLASS stuff is just them sharing a pointer which makes me wonder how well that will work
<enebo[m]1> I guess my first wonderment is @@ and whether method tables can change
<enebo[m]1> fwiw I am totally ok without ractor support at release time
<headius> They do have a lot more off heap data then we do so it may be possible for them to share class and method structures without sharing mutable class data other than that
<headius> Yeah I wanted to poke at this mostly to see how close we can come just wrapping a second jruby instance
<headius> Other than open questions about class sharing, I think we can get pretty far
<enebo[m]1> "Only the main Ractor can access instance variables of shareable objects."
<enebo[m]1> "Only the main Ractor can access class variables."
<enebo[m]1> This one is interesting: "Only the main Ractor can read constants which refer to the unshareable object."
<enebo[m]1> TABLE = Ractor.make_shareable( {a: 'ko1', b: 'ko2', c: 'ko3'} )
<enebo[m]1> oh my
<enebo[m]1> It just ends up being a proxied instance but I don't like the notion of combos here...like a class has a constant with a shareable hash
<headius> So perhaps it is proxying access to shareable objects through some indirection?
<headius> This is all very complicated and it doesn't seem like it needs to be
<enebo[m]1> It is seemingly a one person vision of something he had no experience with until he started on it
<enebo[m]1> Or at least he had not been working with any existing solutions
<enebo[m]1> He did spend years on it though so I will not write it off at this point
<enebo[m]1> man this facebook stuff is funny and amazing
FlorianDoubletGi has quit [Ping timeout: 264 seconds]
FlorianDoubletGi has joined #jruby
<headius> it might be possible to just enforce the immutability or marshaling and do b
<headius> basically nothing else
<headius> just let threads run as they do today
<headius> the block is actually running in a different runtime but zero work here to migrate it or the strings safely
<headius> there seems to be no test specifically for Ractor API in the main test suite
<headius> $ jruby -rjruby -e 'p JRuby.ref(self).runtime; r = Ractor.new { str = "hello"; p JRuby.ref(str).runtime }; r.take'
<headius> #<Java::OrgJruby::Ruby:0x67e2d983>
<headius> #<Java::OrgJruby::Ruby:0xc8d1426>
<headius> works to isolate if that block of code has not run before
<headius> this does not ensure closure state doesn't get captured but the literal strings are not constructed until the first run of the block
drbobbeaty_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
drbobbeaty has joined #jruby