lucasallan has quit [Remote host closed the connection]
mrbrdo has joined #jruby
<mrbrdo>
headius: would you consider “Detected invalid array contents due to unsynchronized modifications with concurrent users” a bug without other info?
pitr-ch has quit [Quit: Computer has gone to sleep.]
<mrbrdo>
I just got that, a quick search reveals an old bug but that was for an old version and supposed to be fixed
<headius>
mrbrdo: that *should* indicate concurrent mutation of an array, but there have been a couple times it masked a real bug
<mrbrdo>
I got it during running rspec, and trace comes from rspec mocks
<mrbrdo>
but I am doing concurrent stuff. however I’ve never seen this before and I can’t reproduce it anymore
lucasallan has joined #jruby
<mrbrdo>
it just happened once, all my specs failed with the same error
<mrbrdo>
the trace ends at gems/rspec-mocks-2.14.4/lib/rspec/mocks/proxy.rb:120:in `clear'
mister_solo has joined #jruby
<mrbrdo>
also from here actually gems/rspec-mocks-2.14.4/lib/rspec/mocks/proxy.rb:135:in `record_message_received’, which might be in a different thread
<headius>
yeah, perhaps this is just the third one
baroquebobcat has joined #jruby
<headius>
but seems like a similar case
mitchell_ is now known as mitchellhenke
bjfish2 has quit [Quit: bjfish2]
rsim has quit [Quit: Leaving.]
<headius>
the true value set inside the thread doesn't appear to be reflected outside the thread
<headius>
er, the false value... the flag
<headius>
the subsequent code runs until the sleep 1 expires and then receives an exception
<subbu>
could it be thread poll related?
<headius>
I don't think so
<headius>
the value just isn't updating
<headius>
the thread poll fires exactly when I'd expect t to...but we shouldn't get to it in this code
camlow32_ has joined #jruby
camlow32_ has quit [Read error: Connection reset by peer]
<headius>
this is why I was worried about the local variable optimization...after the closure, the flag could be updated at any time...so just unloading into a local it and using the local is not good enough
camlow32_ has joined #jruby
<headius>
worried = last week when I saw this
calavera has joined #jruby
<headius>
a simple case works fine though...hmm
<headius>
$ jruby -e 'def foo; a = 0; pr = proc { a = 1 }; p a; pr.call; p a; end; foo'
<headius>
0
<headius>
1
x1337807x has joined #jruby
camlow325 has quit [Ping timeout: 244 seconds]
iamjarvo has joined #jruby
lucasallan has quit [Remote host closed the connection]
<subbu>
headius, if you can dump the IR that JIT generates for those 2 scopes ... it would be easier to see what is going on.
<headius>
yeah I'll try
<subbu>
before the sleep 1 is hit, the tmp should get written back into the lvar slot in dynscope.
<enebo>
lopex: Perhaps I need to use EncodingService.loadEncoding(ByteList)
<headius>
subbu: it should be possible to only load the value from binding if the binding has been captured too
<lopex>
enebo: depends
<lopex>
enebo: are you sure it's not an alias ?
<headius>
probably via "t = load temp var; t = IRRuntimeHelpers.loadFromBindingIfEscaped(scope, variable, t)
camlow325 has joined #jruby
<enebo>
lopex: I don’t think it can be but it maybe does not matter
<lopex>
enebo: lower level EncodnigDB.getEncodings().get is also case insensitive hash
<enebo>
lopex: I am saying a bytelist and asking Encoding.getName()
lucasallan has joined #jruby
<enebo>
lopex: So getName represents real name or also could it be a class representing an alias?
<subbu>
headius, in a meeting .. back here later.
<enebo>
lopex: Ultimately, I do not want to save and lookup by name but I am willing to do this now because I thought it would be easier
<lopex>
enebo: or findEncodingOrAliasEntry
<enebo>
lopex: I might try EncodingDB since it is static and I know I will need to change this
<enebo>
lopex: atm I just want things to load and I am not too concerned with weird encodings
<enebo>
lopex: but I will wire in EncodingService into this long run and call through that
<enebo>
lopex: life on the edge: return EncodingDB.getEncodings().get(decodeByteArray()).getEncoding();
<enebo>
which worked!
<lopex>
yeah, it will
<lopex>
isnt alias aware though
<enebo>
lopex: but can a live Encoding instances getName return an alias?
e_dub has quit [Quit: e_dub]
_elia has quit [Quit: Computer has gone to sleep.]
<lopex>
live or alive ?
elia has joined #jruby
aramisbear has joined #jruby
saga65 has quit [Quit: (null)]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] enebo pushed 1 new commit to master: http://git.io/pwSu
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
jruby/master b173aca Thomas E. Enebo: Encoding and Decoding now understand how to encode/decode byte[] and Encoding....
elia has quit [Client Quit]
<enebo>
lopex: a live instance whihc is alive
<enebo>
lopex: The difference does not differ for me I guess :) I just mean when I save encoding I am calling getName on an instance of an Encoding object
<enebo>
lopex: So do aliases get their own instance of Encoding?
<lopex>
enebo: aliases is a separate hash in encoding db
<enebo>
lopex: ok so getName() will always be the non-alias name
<lopex>
enebo: both hashes hold entries (which in turn lazily load encdings)
<enebo>
lopex: which I think means I do not need to search aliases for persisting an encoding
<lopex>
enebo: finding aliases requires iteration
<lopex>
er
<lopex>
wait
<lopex>
aliases of a specific encoding ?
shellac has quit [Quit: Ex-Chat]
<enebo>
haha
<enebo>
lopex: I have a instance of a bytelist loaded in jruby and I want to write out it’s bytes with its encoding (and coderange)
<lopex>
yeah, that would too
<enebo>
lopex: The instance of Encoding in that bytelist will have a getName
<enebo>
lopex: That getName will never return an aliased name
<enebo>
lopex: That is the conclusion I got
kares has quit [Ping timeout: 264 seconds]
<lopex>
yeah
<enebo>
lopex: so if so I don’t care about aliases at all
<enebo>
lopex: thanks!
<lopex>
enebo: there's a huge bug in encoding lists btw
<enebo>
lopex: Thanks for fixing it in advance
<enebo>
:)
<enebo>
lopex: I will buy you beers when we get together
<enebo>
lopex: …in person
<enebo>
lopex: If you are not the person in a picture I saw and instead is just a brain in a jar…I will pour the beer into your jar.
<subbu>
headius, looking at that gist now .. it seems that treating thread-poll instruction as a data flow barrier will fix this problem.
<headius>
dunno if that's helpful though
<headius>
subbu: ahh, that's a good idea
<subbu>
headius, no .. it is fine .. the fix is simple. i was just reporting a cfg debug output bug.
<headius>
ok
<subbu>
headius, yo should be able to fix this by changing flags in Operation.java
<headius>
oh sure, makes sense
<subbu>
i haven't looked at the code in AddLoad .. code yet .. depends on how that pass uses htose flags .. but iirc, tht pass should be using those flags.
<subbu>
still in meeting .. just stealing away for a few mins when i had a break in my participation.
<enebo>
subbu: which part of logging? The double labels?
<headius>
subbu: I'll see if I can hack something
<subbu>
enebo, look at the gist headius shared earlier .. the cfg bb ids doesn't seem to correspond with the instr output below.
<enebo>
subbu: hmm off by one?
<enebo>
BB1 is 0 so >[1, 10] is not wrong but off by one?
brightball has joined #jruby
<enebo>
subbu: yeah I think the < and > lists just need to have +1 added to them
<enebo>
subbu: Although I cannot fathom how long this has been broken
<enebo>
subbu: perhaps when I changed us to using dirgra maybe?
pglombar_ has joined #jruby
<enebo>
subbu: hmmm maybe more broken than just that
<subbu>
enebo, ah off by 1 probably yes .. not sure when the output brok e.. but i have stared at cfgs in the past and all seemed okay then .. but maybe i haven't looked at cfgs for more than 6 months.
<enebo>
subbu: one thing can you confirm for me
<enebo>
BB9 (GEB) the in seems wrong with the +1 theory
colinsurprenant has joined #jruby
pglombardo has quit [Ping timeout: 245 seconds]
aramisbear has quit [Ping timeout: 240 seconds]
kares has joined #jruby
<headius>
subbu: I have a fix, but unsure if it's right
<enebo>
subbu: oh yeah thread_poll can raise. I think GEB is right. So bck to plus one I think.
<subbu>
ok .. back here now for a bit.
<subbu>
headius, ok .. that shoudl work .. verify if StoreLocal... needs it too.
<headius>
I'll check
<subbu>
enebo, ok .. glad it is just off-by-1 .. i would have been surprised if it had been anything else more than that :)
<enebo>
subbu: yeah I have not looked yet but I would be surprised if this was a recent regression on logging too
pglombar_ has quit []
<enebo>
subbu: for headius fix could this be a property of Operation?
x1337807_ has joined #jruby
<headius>
subbu: a perf improvement for the explicit loads would be what I described above... have them take the current local value and check if binding *could* have updated before loading
x1337807x has quit [Ping timeout: 240 seconds]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] bjfish opened pull request #2683: Adding Array#product to array.rb (master...truffle_array_product) http://git.io/prUO
JRubyGithub has left #jruby [#jruby]
<headius>
enebo: I thought the side effect flag would do it, but that seems to be used for other things
<enebo>
headius: I think quite a few instrs are capable of side-effects yeah
<enebo>
headius: with that said I am surprised it would not work
<enebo>
headius: it is maybe way too conservative
<headius>
it probably is
<enebo>
headius: is thread poll the issue because it is raising?
<subbu>
enebo, yes .. it would be too conservative .. i am distracted to look more closely at it.
<enebo>
headius: a fairness thing?
<headius>
enebo: it should not get to the raise
<headius>
obviously there's timing concerns but 1s should be plenty for the flag to propagate
<subbu>
while (lvar) {} <-- .. you need to load the lvar in the while-loop at least once per iter.
<headius>
right
<subbu>
and thread-poll is a good place to force it.
<enebo>
oh I see
<headius>
if it CAN be updated
<headius>
but that's future improvement
<enebo>
this is not about the instr and what it can do
<enebo>
It is just a hint for insertion
<subbu>
there are no guarantees about exactly when it should be loaded in the loop .. as long as it is done once per iteration.
<headius>
and that sort of improvement will improve binding elimina tion too
<subbu>
alright .. back into parsoid land for a while :)
<headius>
btw guys, I ran into a number of other folks at VM Summit that have similar polling
<enebo>
subbu: this seems like if the algo can not figure an exact location it should probably be at front end of loop
<subbu>
but, glad this was just a simple fix.
havenn has quit [Remote host closed the connection]
<headius>
got some advice from JDK folks on limiting impact
<enebo>
headius: I removed it from lots of places the other week
lucasallan has quit [Remote host closed the connection]
baroquebobcat has quit [Ping timeout: 250 seconds]
<headius>
also found out about a C/Fortran to Java compiler that actually works well
<enebo>
headius: well from method prolgue/epilogue (not sure I remember)
<headius>
enebo: cool
<enebo>
headius: so we largely only do this in loops
<headius>
yeah, we probably have it in too many places in Java code too
<subbu>
enebo, i think we can continue to rely on presence of thread-poll to guarantee that it is loaded once per loop.
<enebo>
subbu: yeah makes me think we should document this assumption somehow
<subbu>
sounds reasonable .. even a test if one can be hacked up.
lucasallan has joined #jruby
<enebo>
subbu: yeah..hmm :)
<enebo>
headius: ok first file can be read in and crashes in interpreter
<headius>
yay
<enebo>
headius: which is fine. I think it is just that IRScope is a little warped and needs a little more setup
<JRubyGithub>
[jruby] enebo pushed 1 new commit to master: http://git.io/prcL
<JRubyGithub>
jruby/master 3617d05 Thomas E. Enebo: Add missing call instrs and re-order where result is read from
JRubyGithub has left #jruby [#jruby]
<headius>
hmmm...passes in isolation
<headius>
er wait, no it doesn't
<headius>
bleh...it's the fix
<enebo>
yay
<enebo>
fixed it real good
<headius>
weird
<headius>
oh huh
<headius>
it's a variable first declared after e closure
<headius>
oops
<headius>
subbu: heh, definitely did need the store logic too
<headius>
otherwise the load was not seeing it update
<headius>
we'll have to revisit this to mitigate the cost of loading and storing binding vars
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<subbu>
headius, ok .. but, thread-poll is only once per iteration .. so, shouldn't be a big change from what it was.
<headius>
ok
<subbu>
it only affects vars that are read and that haven't already been loaded .. so in "normal" loop scenarios where there are calls in there .. the loads would ideally have already been added in.
<JRubyGithub>
[jruby] headius pushed 2 new commits to master: http://git.io/prgT
<JRubyGithub>
jruby/master 440c956 Charles Oliver Nutter: IRB needs some tweaks to support running from classpath resources.
<JRubyGithub>
jruby/master 09c29b8 Charles Oliver Nutter: Treat thread polls as variable visibility barriers....
JRubyGithub has left #jruby [#jruby]
<subbu>
headius, ok .. we can look at opt-ing this further later on if we see opportunities.
lucasallan has quit []
<headius>
subbu, enebo: I thought of an easy way to get blocks to JIT btw
<headius>
if a block hits JIT threshold, walk up to its method parent and force that to JIT
<headius>
plus logic in InterpretedIRBlockBody to look for the compiled body
<subbu>
headius, but is there a reason why a block cannot jit just by itself?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] subbuss pushed 1 new commit to master: http://git.io/prV0
<JRubyGithub>
jruby/master 70432b8 Subramanya Sastry: Minor readability tweak to paranthesizing in if condition
JRubyGithub has left #jruby [#jruby]
<headius>
subbu: currently, it's because the passes we run for JIT must be run all the way up to method scope
<subbu>
not true any more.
<headius>
if we don't run them then e.g. var load stores don't align
<headius>
oh?
<enebo>
yeah hypernugget changes
<headius>
if that's the case then it would be even better
<enebo>
HYPERNUGGET
<enebo>
subbu: ^
<subbu>
as in, at least shouldn't be .. all scopes should run passes independently.
e_dub has joined #jruby
<headius>
well, nevermind then :-)
<subbu>
headius, trust but verify ;)
<headius>
indeed
<enebo>
headius: yeah I was going to ask about emitting all closure scopes during method compile. I think we can probably mirror MixedModeMethod and use same infrastructure
<subbu>
headius, hopefully you will find that it is indeed fixed and nothing is broken when you verify.
<enebo>
subbu: we still walk all closures for use-def data
<enebo>
subbu: oh and also scope flags
<enebo>
subbu: I guess in both cases those are pretty neccesary
<subbu>
that is fine .. that is just information. doesn't force code change on those other scopes.
<enebo>
subbu: it is fine but it makes our lifecycle a little more complicated but it is needed so I will not complain about reality
<subbu>
ok :)
<enebo>
speaking of reality persistence is broken in an interesting way
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to master: http://git.io/pro0
<JRubyGithub>
jruby/master f1eab90 Charles Oliver Nutter: Fix spec:profiler....
JRubyGithub has left #jruby [#jruby]
<enebo>
it mucks with all the lifecycle work and simplest fix is 2 fields back on IRScope
e_dub has quit [Client Quit]
<headius>
enebo: what fields?
<headius>
all our suites are back in the passing column
e_dub has joined #jruby
<enebo>
headius: offset to instrs and the live file they are in
<headius>
amazing since I didn't actually fix AOT
<enebo>
headius: I just saw a failure from one of my commits
<enebo>
but it does not fail for me locally
<headius>
enebo: I mean they will be green
<headius>
or should be
<headius>
I'm looking at your failure too
<headius>
oh, that failure is the HOME thing
<enebo>
headius: I tried running that test file with background=false threshold=0 in JIT + -X-C and it passes
tenderlove has joined #jruby
<headius>
intermittent HOME getting cleared in rubyspec runs
<enebo>
oh perhaps -1
<headius>
for hwhatever reason
<headius>
I have never figured out what's causing it
<enebo>
headius: this is frozenliteral == nil
<enebo>
but when I run locally it is “constant” and frozen?
<headius>
oh I thought you were looking at the File specs getitng nils
<enebo>
definitely not nil
<headius>
hmm
<subbu>
headius, so, all suites are now in green then?
<headius>
subbu: yes
Hobogrammer has quit [Read error: Connection reset by peer]
<headius>
we still need to add some other JIT suites but test:mri:jit is pretty extensive
Hobogrammer has joined #jruby
<headius>
enebo: yeah weird
<headius>
defined failures
subbu is now known as subbu|lunch
<headius>
I don't understand the spec diff though
<headius>
test diff whatever
<headius>
[exec] diff:
<headius>
[exec] ? "constant"
<headius>
[exec] ? il
<headius>
what's il?
<enebo>
headius: I have done -X-C thresh:-1, -X-C thresh: 0+background:false, JIT thresh: 0+background:false
<headius>
hmm
<enebo>
Did I somehow commit a prnitln?
<enebo>
that output makes no sense
<headius>
oh nevermind about the diff
<enebo>
This is the only commit which could have broken anything I did recently
<headius>
hmm
<enebo>
we never honored Operation.FROZEN_STRING before this point
<enebo>
all FrozenStrings were marked as StringLiterla
<enebo>
headius: It is possible I really enabled frozen string support and there is a bug in it
<headius>
this does run inside maven but I wouldn't expect anything different
<headius>
enebo: that is possible, yes
<enebo>
headius: If I change it back to STRING_LITERAL it will probably run but what I have is correct
<enebo>
headius: If that is the case then some code snippet is somehow storing nil into a frozen entry in the constant pool
<headius>
I don't see how the frozen string logic would ever return nil
<headius>
oh hell, maybe I do
<enebo>
headius: but not this snippet which is retrieving what it thinkjs will be a string for it
<headius>
hmm
<headius>
I thought maybe weakref oddity but that doesn't seem likely either
Aethenelle has quit [Quit: Aethenelle]
Aethenelle has joined #jruby
lanceball is now known as lance|afk
<enebo>
headius: you looking at freezeAndDedupString?
<headius>
yeah
<headius>
do you have indy on?
elia has joined #jruby
<enebo>
headius: I have default flags
bjfish2 has quit [Ping timeout: 245 seconds]
<enebo>
perhaps that job is enabling indy
<headius>
hmm
<headius>
it shouldn't be
<headius>
anyway it seems ok with indy here too
<enebo>
headius: one thing about this logic is it makes a RubyString to get a RubyString
<headius>
yeah, the intent is that you cache it after that
<enebo>
headius: which is fine for dedup but couldn’t we store bytelist and not construct that over and over?
<enebo>
headius: ah
<headius>
this is to get the frozen, deduped version of an abritrary string
<enebo>
headius: yeah we are just missing the caching from the interp
<headius>
all places that use this should cache
<enebo>
headius: I see
<headius>
hmm yeah ok
<headius>
medium-high priority to fix that btw
<nirvdrum>
What can you guys do differently with a frozen String?
<enebo>
headius: yeah interpreter does not cache but probably not a big deal
<headius>
since it will also dup every time right now
<enebo>
headius: oh actually hahahahah
<headius>
nirvdrum: we don't do anything special right now
<enebo>
headius: I have been sitting watching rails console churn through objects when I am doing nothing and I am thinking wtf
<headius>
indy logic in JIT will treat it as a constant though
<headius>
enebo: ahh yes
<enebo>
headius: there seems to be some loop which is probably hitting lots of frozen strings
<enebo>
headius: It is still mysterious to me since we have to have some active thread since it is blocked at a prompt
<enebo>
headius: but the churn is pretty noticeable
<enebo>
headius: at least from jvisualvm
<headius>
hmm
<headius>
these defined results are already in a cache of their own
<headius>
enebo: it would be very interesting to figure out what's doing that
<enebo>
headius: IRRuntimeHelpers return them as single instances
x1337807_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius>
heh
<headius>
well it has FrozenString as an operand, which it uses to get a Java string, which it uses to get a frozen string out of the defined message hash
<enebo>
oh yeah DefinedMessage
<headius>
seems excessive :-D
<enebo>
headius: consolidation may not be bad here :)
<nirvdrum>
headius: Can you do that whenever a String is frozen, or does it need to be one of these frozen literals?
<enebo>
headius: although this existed long before frozen string
<headius>
nirvdrum: at the moment only a frozen literal
zeroecco has joined #jruby
<headius>
I don't know how far indy manages to propagate that though
<headius>
enebo: yeah thinking the same thing
<headius>
I still don't see why it would be nil though
<enebo>
headius: in truth we could possibly leverage frozenstring for the return value here and eliminate definedMessage altogether
<headius>
yeah I think we can
x1337807x has joined #jruby
<enebo>
headius: helper would return true/false and we would use frozen string operand “constant” if true
bjfish2 has joined #jruby
<headius>
I don't think it's going to fix your issue though
<enebo>
not sure that explicitness helps anything in IR
<headius>
and I still have no explanation
<enebo>
yeah me neither but it is the change of Operation for FrozenString which done broke it
<headius>
hmm
<enebo>
oh
<enebo>
we double back these via bytelist and string
<enebo>
could this somehow be using the string and not bytelist nd getting nil from null somehow?
<enebo>
but if that was the case I would think I could see this failing trivially then
<headius>
CR?
<headius>
yeah we don't need the string
<enebo>
none is 7bit
<headius>
well yeah, but if this is an encoded frozen string it will be decoding to String wrong
<headius>
none of these are multibyte strings though so I don't think that's the problem either
<headius>
RubyModule.fastIsConstantDefined I think
<headius>
just use the non-fast
<asarih>
hmm. eeenteresting.
<headius>
asarih: yes
<headius>
it worked for a build earlier today
<headius>
so I dunno
<asarih>
headius: we are having .com downtime. I'll take a look at this when things calm down.
<headius>
ok, I figured something might be up because travis is really sluggish today
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] enebo pushed 1 new commit to master: http://git.io/poI2
<JRubyGithub>
jruby/master 9ac895a Thomas E. Enebo: Temporary workaround to my FrozenLiteral commit. -J-ea noticed these strings were being used in places where the strings are required to be intern'd. A followup fix will remove these uses of FrozenLiteral (and StringLiteral), but this will fix the ci errors.
JRubyGithub has left #jruby [#jruby]
<enebo>
headius: I think that assertion is useful unless we stopped depending on idents to be interned?
<headius>
enebo: I don't know if we depend on them
<headius>
we've been removing that requirement other places
<enebo>
headius: it might have caught a bug here? :)
<enebo>
headius: It might not have
<headius>
I don't think so
<headius>
I don't think anything in the constant table actually requires the names to be interned anymore
<headius>
it was a preopt to ensure hash had already been calculated
<enebo>
headius: ok well I will fix IR side of this when I am back from errands
<headius>
ok
<headius>
maybe by then builds will have caught up and we'll be 100% green
<enebo>
headius: it is kind of weird we are doing this tbh. I think I am responsible for it because I pushed for a while to have all arguments to an instr be operands
<enebo>
headius: which logically makes sense and could simplify code but it drags on analysis and memory to box the planet
<headius>
yeah definitely
<enebo>
afk
subbu|lunch is now known as subbu
colinsurprenant has quit [Quit: colinsurprenant]
dinfuehr has joined #jruby
<lopex>
numbers ?
<nirvdrum>
lopex: And we're up to 248 contributors.
<headius>
we fixed some big perf regressions after pre1
<headius>
there will be more fixes after pre2
mister_solo has joined #jruby
<enebo>
I think it would be a good goal to be feature complete for pre2 and then improve perf and memory over RC2 with anything which falls out
<enebo>
oh actually destructive keywords is outstanding although I have a fix
viking has quit [Remote host closed the connection]
<enebo>
I am just not sure I like it
<lopex>
numbers!
<headius>
enebo: what's that?
<headius>
the **kwargs stuff?
<enebo>
headius: if you pass a hash as kwargs and use after callsite it is missing all reqd kwargs
<headius>
ahh right, that stuff
<headius>
yick
<enebo>
headius: my patch dup’s in one spot and passes to interp (and we could for JIT) but I don’t love that extra machinery calcing hash before method which then recalcs hash
<enebo>
headius: I also like out of banding kwargs if we are going to do it before interp/jit body but I don’t want to do that now
<headius>
yeah for sure
mister_solo has quit [Ping timeout: 246 seconds]
<headius>
we have flexibility on out-of-band work after pre2
<enebo>
headius: yeah so perhaps I do hash dup for pre2 and we revisit the whole arg processing thing
<enebo>
headius: subbu: might be a good face-to-face when we get to that point
<subbu>
sure.
<enebo>
going to fire up the grill…yippee kai yay?
enebo has quit [Quit: enebo]
colinsurprenant has quit [Quit: colinsurprenant]
havenwood has quit [Remote host closed the connection]
<headius>
oh bother, he left
<headius>
subbu: I have a question
<headius>
you may or may not be able to answer
<headius>
maybe I don't
<subbu>
ok :)
<headius>
I assume the persistence has to be able to reconstitute StaticScope or it wouldn't be able to run
<subbu>
i think so.
<headius>
still debating just making AOT persist the IR into a .class file with a couple entry points to start up interpreter
havenwood has joined #jruby
colinsurprenant has joined #jruby
<subbu>
i haven't kept up with changes in persistence and what enebo has been cooking up .. so, hard to answer that. but, i've been encouraging him to persist have formats that can persist the cfg as well so you can boot up without having to all that stuff online.
mister_solo has joined #jruby
<headius>
subbu: yes indeed
<subbu>
headius, but, i didn't understand your qn. however ... about your debate.
<headius>
it's up for debate what format we'd want to save too
<headius>
ahh well I mean rather than having AOT *actually* emit JVM bytecode, just emit a persisted IR and a main that can call interpreter against it
<headius>
that will let it compile all code out there, still dynamically optimize at boot
<subbu>
i see .. with persisted ir stored as data.
<headius>
I mean dynamically optimize at runtime
<headius>
right
<subbu>
makes sense to me .. having spent 1 minute thinking about it.
<subbu>
:)
<subbu>
since you already have the JIT infra. to compile instrs to bytecode as needed.
<subbu>
i guess one qn. that could inform that decision is .. what happens when we make changes to IR .. with bytecode, that has much lesser of an impact than with persisted IR.
<subbu>
we've made tons and changes to IR format over the last couple years .. and we want to retain some flexibility in making changes to the IR format ...
<subbu>
persistence / and aot reliance on that internal format needs to be able to deal with that ...
<subbu>
with persistence, you could at least throw away the persisted IR and just rebuild since that is just a perf opt and you still have access to original source .. but not so with AOT ..
<subbu>
so headius maybe I am starting to argue against what you were considering?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 2 new commits to master: http://git.io/pKWk