<GitHub146>
[jruby] kares created test-jit-tableswitch (+1 new commit): https://git.io/vMWpe
<GitHub146>
jruby/test-jit-tableswitch 3a0e1ee kares: JIT fixnum cases (with a value span <= 32) as a tableswitch...
bga57 has quit [Ping timeout: 255 seconds]
<GitHub10>
[jruby] kares opened pull request #4430: JIT fixnum cases (with a value span <= 32) as a tableswitch (master...test-jit-tableswitch) https://git.io/vMWpg
vtunka has joined #jruby
bga57 has joined #jruby
thedarkone2 has quit [Quit: thedarkone2]
shellac has joined #jruby
mpapis has quit [Ping timeout: 240 seconds]
mpapis has joined #jruby
claudiuinberlin has joined #jruby
claudiuinberlin has quit [Client Quit]
drbobbeaty has quit [Ping timeout: 255 seconds]
alex0ptr has quit [Remote host closed the connection]
vtunka has quit [Quit: Leaving]
vtunka has joined #jruby
alex0ptr has joined #jruby
alex0ptr has quit [Ping timeout: 260 seconds]
marciol has joined #jruby
drbobbeaty has joined #jruby
alex0ptr has joined #jruby
<GitHub145>
[jruby] chrisseaton pushed 2 new commits to truffle-head: https://git.io/vMlGR
<GitHub145>
jruby/truffle-head e9d732b Chris Seaton: [Truffle] Move the RubyFileTypeDetector to Truffle as we need it to be available to GraalVM.
<GitHub145>
jruby/truffle-head 973ab20 Chris Seaton: [Truffle] Use the logger or polyglot streams instead of System.out and Systeme.err
<byteit101>
Was upgrading a 1.7 app to 9k and noticed that MyJavaClass.java_class.annotation(Java::com.pkg.MyAnnotation.java_class) now doesn't work as annotation only takes 0 and not 1 argument. What is the new way to do this? (finding only the single MyAnnotation Annotations on a java class)
<nirvdrum>
I use fog for that. And not working with fog is a bigger deal I think.
<headius>
the reason this is involved is because there's whole sets of tables for autoload and loaded features that MRI maintains and we don't
<headius>
and lots of code that goes with them
<headius>
it's just not something I've been keen to try to port, and apparently nobody else wants to either
<headius>
fog doesn't work at all?
<headius>
kares: thank you I'm looking into it
<chrisseaton>
headius: Did Duncan MacGregor say he's working with us now?
<nirvdrum>
headius: The fog mock testing system. Autoload is used elsewhere, but I don't think it's catastrophic there.
<nirvdrum>
headius: Interestingly, I do think this is a regression from 1.7. Maybe the logic was just broken a different way there?
<headius>
chrisseaton: yeah he mentioned it a while back
<headius>
nirvdrum: that's possible, but after 1.9 they started adding a lot of these caches
<headius>
it's possible MRI 1.9 has similar problems they fixed and we didn't
<headius>
in any case it does need to be fixed and I don't have a good idea of the effort involved
<headius>
I assume JT doesn't have this problem
<nirvdrum>
We have other problems.
<headius>
heh
<nirvdrum>
But this one I think we have addressed.
<nirvdrum>
As you know, the logic here is tricky as hell.
<nirvdrum>
If you autoload and throw an exception, the module might've loaded or it might not have.
<nirvdrum>
So I don't think we handle error cases accurately.
<nirvdrum>
We have an "autoload" flag attached to every constant.
marciol has quit [Remote host closed the connection]
<nirvdrum>
And set the path to the constant's value.
<nirvdrum>
I think where it gets tricky is we need to swap out the value for the actual module during autoload, in case anything else refers to that constant (since we don't want it to return the filename).
<nirvdrum>
But if it fails, we're supposed to restore state and treat it as if it hasn't been autoloaded. And we don't do that.
<headius>
well you also need this separate table mapping files to autoload constants
<headius>
oh well I guess your case wouldn't because it overwrites the constant
<nirvdrum>
Yeah. The mapping is effectively managed within the constant.
<nirvdrum>
Note when I did this, I had no idea what MRI was really doing :-)
<headius>
I believe the reason we have a separate table for autoload is due to all the state changes involved for thread-safe autoloading
<headius>
during autoload it needs to transition to "in autoload" but not overwrite the constant yet
<headius>
other threads that hit it have to know it's autoloading atomically and wait
<headius>
all that
<nirvdrum>
Yeah. I need to look into again, but there's some situation there we don't handle correctly.
<nirvdrum>
I think I got the happy path working and some of the sad paths and left it at that.
<headius>
the worst part is that I'm not even sure how far "thread safe" goes...there's too many states to manage
<headius>
like I'm not sure how safe MRI's logic even is
<nirvdrum>
Sucky.
<nirvdrum>
Well, if I understood the comments on the issue, you hadn't come across a real world case of this yet. So, now you have one :-)
<nirvdrum>
Basically the impact on Module#autoload?
alex0ptr_ has joined #jruby
alex0ptr has quit [Ping timeout: 256 seconds]
<nirvdrum>
Is 9.1.7.0 still set to go out today?
<headius>
no, I need to fix the regression kares figured out at minimum and enebo is working on an IR workflow bug
<headius>
so it will be a few more days
<chrisseaton>
I was seeing the same -X+C bug that I think has now been reported
<headius>
yeah, I tried to get root scopes optimizing like other ones and it looks like it overreaches
<headius>
or we're not setting up runtime state properly for the optimized root scope logic
<nirvdrum>
Well, at least it was caught before the release.
<headius>
indeed
<headius>
only seems to affect -X+C though
<headius>
we don't normally compile root scopes to JVM bytecode...not worth it
<headius>
ugh, may have been simpler than I thought...we weren't setting the containing module for top-level when going through the compiled path