<rebelwarrior[m]>
issue open feel free to add or edit if necessary.
<enebo[m]>
rebelwarrior: yeah I suspect that is enough for someone to try assuming they have an M1 mac to try it on
<enebo[m]>
I wouldn't really expect M1 to be a big deal for unpacking something but who knows
<enebo[m]>
When headius is around I suspect he will be able to repro your Rails 6.1 install issue since he can run on M1
<enebo[m]>
We will open an issue based on that or get back to you
<enebo[m]>
although if you care to you could make an issue for that too :)
<rebelwarrior[m]>
where should I open the issue?
<enebo[m]>
for the railties install open it on jruby project
<enebo[m]>
This almost certainly will be an M1 issue since I can install it on Fedora (and I am not really sure what would not work with railties itself)
<enebo[m]>
Oh unless it is doing some binstub thing and not working? Like chmod or ln
<enebo[m]>
but done from Ruby which would hit doing native calls
<enebo[m]>
rebelwarrior: That is strange when I installed this I did not get mimemagic as a transitive dep
<enebo[m]>
If I had to guess I would it picked mini_mime instead
<enebo[m]>
rebelwarrior: can you try 6.1.3.2 of rails? I wonder if there was a problem early in 6.1 where it was doing the wrong thing for JRuby
<rebelwarrior[m]>
rails issue was not an issue. resolved.
<rebelwarrior[m]>
`gem install rails -v 6.1.4.4` solved the issue they'd migrated to marcel due to licensing issues -v 6.1 tries to install the old one.
<enebo[m]>
rebelwarrior: ah great. So back down to one issue
<headius>
eb11c5de9d9f9e220c6166b440c484639384e291 on 9.3
<headius>
I found an additional related bug: the JIT does not deduplicate frozen strings when first creating them
<headius>
FrozenString operand deduplicates based on the raw bytelist so if some code interns a string and other code is loaded with that same frozen string it will be the same deduplicated object
<headius>
not sure if this just diverged naturally or if something was changed on purpose
<headius>
JIT will cache the frozen string but each unique frozen string will still be created new for that file
<enebo[m]>
headius: oh I should bring this up...I broke JVMVistor with my call to markAsRuby2KetwordArg in emitScope
<headius>
good job
<enebo[m]>
the aload(1) could be a different call but I think it is staticScope but the m.loadArgs is clearly not right
<enebo[m]>
I don't see why though...I thought it was just loading args.
<headius>
hmm maybe I'm wrong, JIT and operand both seem to call the same function to produce the frozen string
<headius>
enebo: I can look at it if you have a repro
<headius>
I assume it is failing some tests
<enebo[m]>
run spec:compiler
<headius>
aha
<headius>
indy mode always creates a new frozen string
<headius>
normal mode does not but normal mode did not exist until AOT work to remove all indy
<headius>
and for this we always use indy still
<headius>
enebo: ok
<headius>
after I fix this
<headius>
oh haha the answer is weirder than that
<headius>
enebo: so I'm not sure about this one...
<headius>
the reason it only affects interp is because interp StringLiteral is evaluated by retriving the FrozenString it contains and duping it
<headius>
that's how yarv does it also
<headius>
so when it dups the FrozenString it picks up any flags like tainting
<headius>
when the dedup cache is afflicted with a tainted string, that means all non-frozen literals of that string will duplicate that tainting
<headius>
JIT mode ignores the contained FrozenString and just caches the ByteList on first access for creating a new string every time
<headius>
so no tainting infection from a bad dedup cache
<enebo[m]>
hmm
<headius>
I'm not sure either way is wrong
<enebo[m]>
so one would argue it should not cache a tainted string
<enebo[m]>
and tainting does not exist in 3.0
<headius>
FrozenString being inside StringLiteral is basically just a way to reuse the FrozenString logic to produce new mutable strings
<headius>
yeah maybe I should just leave it
<headius>
in both cases you get a new string
<headius>
interpreter does it by duping from cache, JIT does it by creating a new object with cached bytelist
<headius>
duping is probably slightly slower because of useless flags propagation
<enebo[m]>
should JIT be returning new Strings in 3+?
<enebo[m]>
It should be using table right?
<headius>
both branches taint fixes are merged fyi
<headius>
well mutable strings always produce a new object
<headius>
so no .freeze or -"string" literal or frozen-literal-string pragma
<headius>
the only difference is how the mutable string object gets created, either by duping a cached frozen version of it or by just creating a new object
<headius>
the JIT certainly could switch to producing new mutable strings by duping from the cache but I would expect it to be a bit more overhead for no real gain
<headius>
it would also move the construction of the new mutable string object further away from the code, and that will impact inlining
<headius>
meh not changing it
drbobbeaty has quit [Ping timeout: 256 seconds]
drbobbeaty has joined #jruby
drbobbeaty has quit [Remote host closed the connection]