<rdubya>
kares: I think this is a foundational issue that will need to be fixed but it isn't currently working so its probably ok to try to shoot for 52 first and see about back porting it
<rdubya>
we haven't heard too many complaints about it yet
<rdubya>
if we could get a patch into AR to pull the type map stuff into a module we may be able to get rid of most of the type map code from the arjdbc gem which would help with future compatibility
<enebo>
kares: rdubya: When I started the 5.0 work my goal has potentially been to reduce amount of code to support but more over to make sure once we strip back to least code we can then re-optimize but we will document the crap out of how, what, and why we deviate.
<enebo>
I think one wrinkle in this plan was that there were JDBC-specific features which are not covered by AR itself
<enebo>
I still have the desire we can make anything which ends up being different from actual AR code either a) move into AR or change ARs connection adapters design b) be well enough documented where a new hacker can see why and what we changed
<enebo>
I think it is hard to say 'a' without having done 'b' though. We somewhat need to prove out changes.
<enebo>
anyways highly abstract spam :)
<headius>
lopex: we could post-process like we do with the parser but I doubt the loading would be as fast as from binary
<headius>
if only we could start using varhandles to read in blocks of ints :-)
<headius>
rdubya: that would be great
<lopex>
headius: memmap :P
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bbrowning_away is now known as bbrowning
mkristian has quit [Quit: This computer has gone to sleep]
<rdubya>
enebo: kares: thoughts on this one: https://github.com/jruby/activerecord-jdbc-adapter/pull/868 ? should I kill the pr and try to come up with a more complete solution for 52 and then try to backport it? Or should I try to get these changes into 50-51 and just improve on it for 52 (and then potentially backport that) ?
<enebo>
rdubya: I think if it can work for 50-51 we should still try and get pg running well
<enebo>
rdubya: so this will improve compat with 50-51 right? I think so long as rails 5.0/5.1 are supported people will keep asking for pg support
<rdubya>
I'm not sure it has a lot of benefits at this point, I think its going to require the bigger refactoring that I mentioned in there where we no longer run #execute and #exec_query through the same path to be able to fix the bigger issues
<rdubya>
but it does fix a couple of the rails tests
<enebo>
rdubya: another thought about this is if all these branches are similar we should be able to merge easier
<enebo>
rdubya: but that is just something to consider
<enebo>
Our whole point of extra release branches is to not have one single codebase
<enebo>
However the closer they are the quicker one-off fixes will be to bubble through each release
<enebo>
rdubya: I guess I trust your judgement though
<enebo>
for mysql/sqlite3 I am going to try and backport as much as I can but they are a lot smaller
<rdubya>
yeah, I think either way I'd want to port it to all three versions, its just whether i focus on making the bigger change for 52 and go down or 50 and go up lol
<rdubya>
since its likely to affect all three dbs as well
mkristian has joined #jruby
mkristian has quit [Quit: This computer has gone to sleep]
<GitHub133>
jruby/master 6a0bb07 Charles Oliver Nutter: Clean up some deprecation in exception logic.
<GitHub159>
[jruby] headius pushed 1 new commit to ruby-2.5: https://git.io/vAi9j
<GitHub159>
jruby/ruby-2.5 d6b2547 Charles Oliver Nutter: Bundler is installed with RubyGems and part of stdlib now.
<GitHub36>
[jruby] headius pushed 1 new commit to ruby-2.5: https://git.io/vAiHJ
<GitHub36>
jruby/ruby-2.5 96b264b Charles Oliver Nutter: Remove bundler from gitignore.
<GitHub16>
[jruby] headius created generify_tojava (+1 new commit): https://git.io/vAiHp
<GitHub16>
jruby/generify_tojava ff88982 Charles Oliver Nutter: Generify IRubyObject.toJava to make it more pleasant to use....
<GitHub7>
[jruby] headius opened pull request #5063: Generify IRubyObject.toJava to make it more pleasant to use. (master...generify_tojava) https://git.io/vAiQv
<headius>
kares: enebo: ^
shellac has joined #jruby
subbu is now known as subbu|lunch
<GitHub20>
[jruby] headius deleted parallel_exceptions at 5dccc5a: https://git.io/vAijY
sidx64_ has joined #jruby
<GitHub192>
[jruby] eregon created update-specs (+2 new commits): https://git.io/vAPen
<GitHub192>
jruby/update-specs 3847b78 Benoit Daloze: Update to ruby/spec@cbe855c
<GitHub192>
jruby/update-specs 249c43a Benoit Daloze: Update to ruby/mspec@d287466
<ChrisBr>
headius: I also looked into bootsnap, however, it makes heavily use of RubyVM::InstructionSequence which does not exist in JRuby. Do you have any idea how to solve this? Bootsnap basically compiles the ruby code and stores it in a cache (implemented in C)
<ChrisBr>
is there an equivalent to InstructionSequence in JRuby which we could use? Or does it even make sense to do that in JRuby?
<headius>
ChrisBr: hi there!
<headius>
thank you for that one!
<headius>
so I'm curious how much that really helps bootsnap
<headius>
I mean worst case we just omit bootsnap altogether on JRuby, but what we've found is that our own IR dumper/loader is not really faster than just parsing and compiling again
<enebo>
headius: ChrisBr: at this point yeah and it is even lazy but laziness may be a worthwhile virtue
<enebo>
lazy methods still hold onto open serialized data but they do not stand up objects so 80% of the methods generally never make it past that point
<enebo>
this ends up using less memory
sidx64_ has quit [Ping timeout: 265 seconds]
<enebo>
With that said, I am hoping to get to redoing const-related IR instrs. We emit an instr + branch per '::' and that ends up making lots of extra instrs for packages like Rails which refer to long constant changes
<enebo>
After a little more instr diet we maybe will get a little better
<enebo>
All-in-all there are two issues with IR persistance: 1) we saved at earliest point because it was simplest to impl but that does not allow us to get benefit of getting CFG and conservatively optimized instrs 2) our design forces every instr and operand to decode to a Java object and that is virtually all the cost of loading
<headius>
ChrisBr: so we *do* have an API for dumping and loading, and it would be worth seeing if that actually helps
<enebo>
changes = chains
<headius>
I'm not sure if it's fully functional at the moment...we have to update it when we make medium-sized IR changes and have not done that for a few recent things
<headius>
ChrisBr: if it's a wash it's still valuable to have it in there...if it's slower than just starting from scratch then our bootsnap could just not bother with saving IR
<enebo>
err heh ir.writing and ir.reading are the two options you want to play with persistence
<headius>
yeah
shellac has joined #jruby
<headius>
those flags passed to JRuby *should* make it write out and then read in persisted IR
<headius>
enebo: last time I tried on something nontrivial it blew up though
<enebo>
in a 100% complete system set both to true
<headius>
I also think I had trouble doing just read without write
<headius>
before they'd been written out that is
<enebo>
headius: yeah it should work though so I would love someone to find issues so we can add maybe to AOT specs
<nirvdrum>
headius: As a follow-up to yesterday, that readIntArray method is also used in UnicodeEncoding.CodeRangeEntry#getRange, which is loaded when compiling a regexp with joni.
<enebo>
since those depend on most of that
<headius>
nirvdrum: another one-shot loading process?
<headius>
hmmm
<headius>
the compiler specs could be expanded to also test AOT
<headius>
right now they test IR in various modes and JIT
<headius>
they're not a complete spec but they cover a wide array of syntax that I've broken over the years
<enebo>
we have an AOT target now right?
<nirvdrum>
headius: It's cached, but it does hit it 4 times -- once for each character type. No big deal, but something incurred on every boot.
<headius>
I guess another option is running some subset of language specs with IR persistence on
<headius>
nirvdrum: ok, well there's room for more improvement I guess
<headius>
I assume the buffering has helped there also
<enebo>
I wish I would have taken a different tack on persistence and testing instrs
<nirvdrum>
It should, yes.
<enebo>
perstence is much more brittle though that it should be
<headius>
enebo: well there's jrubyc AOT which creates a class that simply contains the persisted IR
<enebo>
so at this point filling out one of our spec runs should just keep happening
<enebo>
yeah I meant that
<headius>
the -X+C "AOT" just forces threshold to 0
<headius>
ok
<enebo>
since it uses IR persist
<headius>
if you have read + write properties does it always write then read?
<headius>
I mean for new stuff
<enebo>
logically anything in that has to also work in IR persist sans the filesystem/hash code
<ChrisBr>
headius: enebo: thanks
<ChrisBr>
will look into that
<headius>
as a way to exercise it we'd obviously like for it to always write out and then read in before executing
<enebo>
headius: it is possible to control each independently just as a debugging convenience
<headius>
ChrisBr: there's some Ruby code in jrubyc that exercises the IR persistence directly
<enebo>
headius: there is no useful logic past development itself
<headius>
that would be a good primer without going into Java
<enebo>
I have always wanted IR to have an assembler :)
<headius>
make one
<headius>
:-D
<headius>
my work on the pretty printer was supposed to be a precursor to making an ASM
<enebo>
yeah I haven't because I realize it is one more thing to maintain whenever instrs change
<headius>
it ended up just being a pretty printer
<headius>
I figured for ASM we'd want it two-way but I only got the one way and it's not really a nice source format
<headius>
it could be
<enebo>
my main motivation was to make IR assembler stubs for native methods we could cheat inline into code
<headius>
ChrisBr: we are always interested in startup time too, so this is an opportunity :-)
<headius>
enebo: persistence + AOT is something we did not try