<headius[m]>
it was exactly what I thought but I did not see this over the weekend
<enebo[m]>
I think we can up 9.2.9 timeline once load/require is done for faster release
<headius[m]>
yeah that seems fine
<headius[m]>
9.2.8 was way too long again
<headius[m]>
I'll mark this for 9.2.9
<headius[m]>
enebo: kares did you see that @file thing I proposed for our launcher?
<headius[m]>
I have not done the work for the native launcher yet but the bash script works nicely
shellac has joined #jruby
<enebo[m]>
I am thinking about the notion of a default file
<enebo[m]>
I think we have to provide something for sure
<enebo[m]>
I sort of wish it just handled the opens itself vs anything
<headius[m]>
what do you mean
<enebo[m]>
it will allow any jvm-specific values vs just giving a hatch for this module settings
<enebo[m]>
so my fear with that is people will end up forgetting they put stuff in that file outside the opens themselves and it will generate non-issue reports
<headius[m]>
kares: something about math fixes would be good
<headius[m]>
* More robust handling of optimized call paths for Fixnum, Float
<enebo[m]>
I am doing some measurement of --dev rails c for memory improvement
<headius[m]>
* Reduced runtime generation of specialized objects and variable scopes
<headius[m]>
if it were just one thing thatmight not be interesting enough, but this also includes the 50-wide limit to RubyObject specialization
<headius[m]>
before we were generating any size, and I saw some >100-wide objects in one app
<headius[m]>
and the DynamicScope pregeneration is in there
<enebo[m]>
~24% memory reduction on single model/controller rails app via --dev
<headius[m]>
nice
<enebo[m]>
so what would be a good line for this. Some data reductions with specialized objects and fixnum operand cache but most of this is from reducing memory associated with the program info itself
<enebo[m]>
or maybe that distinction is not so important
<enebo[m]>
We do reduce both to some extent
<headius[m]>
Probably not important
<enebo[m]>
- Substantial memory reduction (~24% less heap with a simple Rails app)
<enebo[m]>
very weird how ' - ' becomes a round bullet in riot.im
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius[m]>
I'm going to try to streamify the logic for setting up class and interface proxies...maybe remove a few steps and intermediate collections while also making it possible to bind some informative stubs
<headius[m]>
there's no way that's more efficient than nested loops
<headius[m]>
streams continue to mystify me...I have found almost no places where they're better than a hand-written loop
<enebo[m]>
yeah it is really just for a nice literate sequence but it is virtually never actually efficient
<enebo[m]>
good enough for lots of stuff though
<headius[m]>
I'm trying to figure out how to pass some stream logic through from the top levels of proxy class initialization to the method loop
<headius[m]>
but the method loop walks each class, chunks off method by name, replaces some methods with those on parent classes...it's difficult logic to invert
<headius[m]>
we build up all these intermediate collections and then almost immediately throw them away
<headius[m]>
hmm
<headius[m]>
may be we don't need to chunk by name since we do that again later
<headius[m]>
setting up the methods in the proxy also requires aggregating them by name so we do a second grouping
<enebo[m]>
I was trynig to closurify IRClosures to be both lexical closures when dryrun and nested
<enebo[m]>
I have it stashed but I did not find it super elegant :)
<headius[m]>
there's also no easy way to stream a chain of objects like class.getSuperClass.getSuperClass....
<enebo[m]>
It will save a field for IRScope and lexical closures are almost never actually used
<headius[m]>
at least not until Java 9 which has a takeWhile stream operation
<enebo[m]>
heh the work for 100k of memory
<enebo[m]>
If that
<headius[m]>
Stream.iterate(cls, Class::getSuperClass).takeWhile((c) -> c != null)
<enebo[m]>
My other reason for considering it new eyes always think it will be populated
<headius[m]>
every k counts
<headius[m]>
to someone anyway 😁
<enebo[m]>
heh yeah
<headius[m]>
hmmm
<headius[m]>
might be I can move some of these predicates into a cached structure
<headius[m]>
per class we already cache the declared methods Method[] but without any grouping or filtering by accessibility
<headius[m]>
I think I can do grouping and accessibility once at that level and then all repeat walks of that class will only see valid candidates
<headius[m]>
JI is a good chunk of startup too...not positive it's this method gathering but that's got to be part
<headius[m]>
hmmm
shellac has joined #jruby
<enebo[m]>
headius: yeah I was using async prof and it was a pretty reasonable x-axis of flames
shellac has quit [Quit: Computer has gone to sleep.]
<headius[m]>
I need a project with a ton of JI
byteit101 has joined #jruby
<byteit101>
headius[m]: I see 9.2.8 is out, but without a new jnr-enxio jar or the changes from my PR to that that the jruby PR depended on (Win IO)
<headius[m]>
o_O
<headius[m]>
how can that be
<byteit101>
Jar pom properties shows June 7th for jnr-enxio build
<headius[m]>
ah blast...I didn't notice the PR didn't update the enxio version and never updated it myself
<headius[m]>
I guess we never verified that master was working for you?
<byteit101>
Ah, yea, I figured you'd update it closer to release time, so just left the pom update to 0.22-snapshot locally and never committed. I veritfied with that still local
<headius[m]>
and enxio never got a release...guess we dropped the ball on getting everything in place after the PRs merged
<headius[m]>
enebo: ^
<headius[m]>
I guess we need a better process here
<headius[m]>
GH has such garbage tools for managing a release pipeline
<headius[m]>
well some consolation...we didn't get in another quick change to support DragonFly BSD and intend to put out a 9.2.9 much quicker than 9.2.8
<headius[m]>
I'm going to take care of flipping these versions now
<headius[m]>
I guess that's what we get for not having a windows CI checking that stuff's actually working
<headius[m]>
byteit101: can you come up with a test or spec that would exercise this?
<headius[m]>
could be a rubyspec but this is pretty edge casey
<byteit101>
sure, but will have to grab my win machine in a few hours
<headius[m]>
enxio 0.22 is on its way to maven now