<lopex>
I'm somewhat reluctant to the suggested change in that issue since it might diverge from onigmo in behaviour
<lopex>
headius[m]: btw those unsave version could be autogenerated via proxies
<lopex>
*versions
<lopex>
is apt still a thing ?
<headius[m]>
we still use annotation processing but on newer JDK you have to pull it from a maven artifact
nirvdrum has quit [Ping timeout: 240 seconds]
<lopex>
I'll give it a more thought while getting home
enebo has joined #jruby
<headius[m]>
enebo: so hey about that constant change
<headius[m]>
I have it on a branch so I could try a few things out, but the latest attempt is green
<headius[m]>
I was planning to cp over to irscope remove branch
<headius[m]>
then I can finish making AOT mode use no indy sites
<enebo>
headius[m]: moving over to branch is fine
<headius[m]>
do we have any testing for inliner?
<headius[m]>
like in CI
<enebo>
headius[m]: inliner is compeltely broken on that branch
<enebo>
headius[m]: but I may be able to unbreak it since I believe I can pass StaticScope into profilingcallsite and only get IRScope when things look interesting
<enebo>
but I need to spend time verifying that
<headius[m]>
ok so I shouldn't sweat that too much
<headius[m]>
pushed the change
<enebo>
headius[m]: yeah I will try and analyze what is needed after .10 but I am hoping it is not too bad
<headius[m]>
ok
<enebo>
headius[m]: I think the other problem is we used to irscope.compilable = method in the method constructors
<enebo>
headius[m]: that was the other isssue
<enebo>
if that had been left we would need to immediately create irscopes
<headius[m]>
ah yeah
<enebo>
so main issues is detect interesting probably is no big thing since staticscope exists
<enebo>
linkage from irscope to method the ir is in is outstanding and I am not sure of best way here
<enebo>
meh heh ... anyways something to figure out before we merge
<headius[m]>
yeah
<headius[m]>
well inlining has never gone live really so it's still in flux anyway
<headius[m]>
enebo: so here's a harder question
<headius[m]>
all paths to creating SearchConstInstr, for example, are now passing CurrentScope.INSTANCE
<headius[m]>
I suppose it's ok to leave it that way since otherwise it ends up being an implicit load of scope
<headius[m]>
which we can't change in the future without adding an operand again
<headius[m]>
hmm
<enebo>
headius[m]: yeah the point of that operand I believe is that if that is in an inlined scope then we can replace it with something else
<headius[m]>
right, that seems an ok place to do it then
<headius[m]>
maybe some small value in having a LoadCurrentScope instr for all of them but that introduces temp usage again
xardion has quit [Remote host closed the connection]
enebo[m] has joined #jruby
<enebo[m]>
yeah I am asking subbu about this offline but I am a bit at a loss after talking about this with you the other day
<enebo[m]>
with that said, this is not really conducive to putting out a release either. I also don't know how this affects JIT at all but I guess you are working on constant lookup so you are just trying to understand what may or may not be associated with that operand?
<enebo[m]>
as of today I think a comment and just assume current staticscope?
<enebo[m]>
Later today I will see what happens when we inline something with a constant lookup in it
<enebo[m]>
I am looking in InlineCloneInfo and I do not see how scopes are adjusted at all
nirvdrum has joined #jruby
<enebo[m]>
Oh well we are talking about live values
<enebo[m]>
so %current_scope in both scopes are currently temps and both hold their own staticscope instances which may be different
<enebo[m]>
by switching to just using the operand then unless we make that operand a caching per scope value then just using that will break inlining
<enebo[m]>
we can still fix this by having guest scopes (of method and block) to replace %scope with a tempvar and then assign it
<enebo[m]>
but that has to be the reason why this was designed the way it is
<enebo[m]>
I do not know of any other potential pass which will migrate instructions into a different lexical scope so this as a one-off probably is fine
<enebo[m]>
as a simple up front copy it was a simple generic solution
<enebo[m]>
I do think working around it is better for interp and for serialization since we will store/do less
<headius[m]>
yeah it will have to get that scope from somewhere so there's got to be something to replace that CurrentScope operand with anyway
<headius[m]>
previously it would have been indirected through a temp but it's really not that much different now...just need a different operand
<headius[m]>
and this simplifies the non-inlined case which is always CurrentScope
<enebo[m]>
A variable for guests in inlining is probably simplest
<enebo[m]>
but it is just another operrand I guess
<enebo[m]>
This literally is +1 to all interp arrays and +1 instr +2operands per serialize so I am on board
<headius[m]>
LoadInlinedScope or something
<enebo[m]>
no jst %v_20 and set it to guest staticscope
<enebo[m]>
e.g. just alloc a temp and store the value
<enebo[m]>
no growth in operands or instrs to support that
<headius[m]>
yeah sure
<headius[m]>
and rewrite the child instrs that depend on scope to use that
<enebo[m]>
yeah it is "special" logic the inliner will need to be changed to do whereas before this was generic as it was done via a variable even if it had a special name
<enebo[m]>
but that is ok
<enebo[m]>
Now that I have come full circle I can appreciate how this prologue copy was a generic solution to this problem
<enebo[m]>
but we do not want to pay the small cost it imposes
<enebo[m]>
and had 2-3 passes needed to worry about instrs migrating scopes it probably would be the superior soln...but it is just inlining
<enebo[m]>
ultimately though cloneForInlining on CurrentScope will just ask for a temp and write the current staticscope to that
<enebo[m]>
current == guess scope being inlined
<enebo[m]>
afk a few
<headius[m]>
I did a refactor to separate the "indy" and "simple" compilation a bit better in org.jruby.ir.target
<lopex>
even if the chance hitting TransZero is like 0.5%
<lopex>
the cache effects could be huge riught ?
<lopex>
and like in polish it's more like 10%
<lopex>
but it's just my wild speculation
<lopex>
sure we can suck at emojis and the other long chars
<headius[m]>
hmm could be, I don't know
<headius[m]>
1024 bytes wide
<lopex>
you mean cache line ?
<lopex>
or the array ?
<headius[m]>
just thinking about the effects here
<headius[m]>
I mean the array
<lopex>
shure it will go in and out
<lopex>
most eu languages are two bytes max
<headius[m]>
so you're thinking if's that check a range would potentially optimize better than going to this table
<lopex>
potentially
<lopex>
er, both
<lopex>
ranges check and lookup
<headius[m]>
yeah
<lopex>
we still have to range check the string
<lopex>
but the most common case is one and two
<headius[m]>
we check one <= already so we'd be adding two more of decreasing probability while eliminating the array access entirely
<enebo[m]>
does cref ever change?
<lopex>
and then we check for 10xxxxxx
<enebo[m]>
I believe all uses of it setting are upon definition
<lopex>
er 11..
<enebo[m]>
one eval case maybe it changes?
<lopex>
enebo[m]: is that a comment on this issue ?
<enebo[m]>
no I don't think even then
<enebo[m]>
hell no
<enebo[m]>
:)
<headius[m]>
hahah
<lopex>
enebo[m]: well, I already made a theory to rationalize it :P
<headius[m]>
cref never changes I think
<enebo[m]>
just auditing currentscope and so I believe this nth scope stuff would only be relevant in the presence of an eval
<headius[m]>
I was even wrong about constants in module methods...they always use lexical scope and the module's inheritance hierarchy, not the included hierarchy
<lopex>
headius[m]: btw, still no hope for that hardware counter thingies for measuring perf ?
<headius[m]>
maybe? I have not revisited it lately
<headius[m]>
the tools that exposed it depended on hooking into linux kernel so I can't easily measure it on MacOS anyway
<headius[m]>
I still end up going to assembly or ideal graph to investigate performance
<headius[m]>
which would be applicable here
<headius[m]>
graal JIT might see through a final array access