bga57 has quit [Quit: Leaving.]
bga57 has joined #jruby
_whitelogger has joined #jruby
Joufflu has joined #jruby
Joufflu has quit [Quit: Leaving]
ChrisBr has quit [Remote host closed the connection]
ChrisBr has joined #jruby
shellac has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
shellac has joined #jruby
shellac has quit [Client Quit]
shellac has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
shellac has joined #jruby
jrafanie has joined #jruby
jrafanie has quit [Client Quit]
<headius[m]> lopex: so I went with a brute force option in https://github.com/jruby/jruby/pull/5733
shellac has quit [Quit: Computer has gone to sleep.]
<headius[m]> basically MRI goes straight to win32 APIs to get the codepage number, formats that as ("CP%u", codepage), and then looks that up in encodings
<headius[m]> so I made our logic match `/^MS([0-9]+)$/` and try the CP version of the name before falling back on default external
<headius[m]> it's not pretty but it should be mostly reliable
<headius[m]> the perfect option would be to mimic their win32 calls but I really don't want to depend on native downcalling just to get the filesystem encoding at boot
<headius[m]> lopex: enebo review if you get a chance
mistergibson has joined #jruby
<headius[m]> enebo: another thing I didn't get to chat about yesterday...
<headius[m]> I merged in the change that limits reified instance variables to 50
<headius[m]> mostly an arbitrary choice...so I have a couple conundrums
<headius[m]> 1. What's actually a useful size? We know there's a handful of objects in the system with a ton of instance variables, but I guess I don't have a good feel for a good limit. With too low a limit most variables will spill into vartable array; with too high a limit I guess the only real down side is generating really wide objects for those few cases
<headius[m]> 2. The current logic statically gathers the local var names and puts them in the set...so the first N variables it actually reifies will largely be random. I'm thinking about heuristics for which variables might be the most valuable, like sorting by access count or considering variables close to target class in hierarchy before variables used by other methods in other ancestors in the hierarchy
<headius[m]> the eventual change I'll make is to actually allow the object shape to evolve dynamically, so if new variables come along then future allocations will use the wider object
shellac has joined #jruby
<enebo[m]> headius: I was thinking about this even though we did not talk about it and I think looking at number of ivars on some reasonably complex AR instance may be a reasonable upper limit
<headius[m]> but same questions apply there...when do we stop, which variables are most important, how deep do we want to go on profiling that
<enebo[m]> What AR model object? I don't know but I do know it creates quite a few ivars
<enebo[m]> Or I should say it is the thing I believe which creates the most commonly
<headius[m]> it should be possible to do an OQL query against VarTableManager instances and get a histogram of sizes
<headius[m]> that would be actual live counts as well, not statically determined
<enebo[m]> yeah that would be pretty interesting to see
<headius[m]> staticallly it only looks at literal @var set/get and attributes
<enebo[m]> yeah and AR has a lot of magic
<headius[m]> right
<enebo[m]> well none of the columns would show up at all
<headius[m]> so none of those reify now...that would be version 2
<headius[m]> I believe even Truffle languages set an upper limit on reified object width
<enebo[m]> ah yeah so those would end up in an array regardless
<headius[m]> this could also be a combined heuristic based on how many vars, how many objs actually being allocated, how heavily the vars are being accessed
<headius[m]> actually the more interesting metric I suppose is how many of each type of reified RubyObject are being created
<headius[m]> I'll get that number with scaffolded app
enebo has left #jruby [#jruby]
rusk has quit [Remote host closed the connection]
<enebo[m]> #jruby
enebo has joined #jruby
* headius[m] uploaded an image: image.png (321KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/McirRrlOhxvfYHbVGgMoppHd >
<headius[m]> so that's just at idle
<enebo[m]> yeah and the model you made has how many columns to hold?
<headius[m]> I'll do an alloc profile for 30s siege
<enebo[m]> If you hit it a few times you may see it spike?
<headius[m]> 4 columns in the model I guess
<headius[m]> this is just what stays in memory after a 30s siege and forced GC
<enebo[m]> 54
<enebo[m]> hmm I wonder what that is
<enebo[m]> 20 instances
<enebo[m]> you make 20 threads?
<enebo[m]> -t 20 or something ... not sure we would have 54 fields on arjdbc connection but you never know
<headius[m]> vast majority of allocs are byte[] for strings
<headius[m]> this is -c 10
<enebo[m]> 27 may be that then
<headius[m]> 50MB of byte[] allocated for 30s 10-way siege
<headius[m]> oh well sampled, so who knows how much for real
<enebo[m]> interesting although you are rendering a lot so I wonder how big a response is?
<headius[m]> next biggest is int[] which is maybe a little odd
<headius[m]> then IRubyObject[] which will be a mix of unreified ivars and args passing
<enebo[m]> int[] still exists for mailer
<enebo[m]> although that should be a small number of instances
<enebo[m]> but big arrays
<enebo[m]> yuuge in fact
<enebo[m]> makes me think ragel may have been a poor choice for that gem...I don't think LALR parser would generate nearly that many states
<enebo[m]> but LALR algos do a lot of state reduction and I wonder if ragel does any
<enebo[m]> Where did ragel even come from?
<enebo[m]> I do know zed was the original pied piper
* headius[m] uploaded an image: image.png (321KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/KrKIOYeRfOEIJkOvIPZVGIFZ >
<headius[m]> int[] for mailer?
<headius[m]> I don't understand that
<headius[m]> not a fixnum array... int[]
<headius[m]> ugh that's not the one
* headius[m] uploaded an image: image.png (596KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/qgnFfztxtUOSWTLqkfCAMREs >
<headius[m]> the formatting from visualvm sampler sucks
<headius[m]> RubyObject14 is probably the model object
<headius[m]> interesting how top-heavy this alloc profile is
<nirvdrum> headius[m]: Did you see that Excelsior JET is now discontinued?
<headius[m]> I did not, that's too bad
<nirvdrum> Yeah. I had never used it, but it sounded like a good product.
<nirvdrum> I know you were looking at it for JRuby. If you have a license already, it's perpetual. But relying on it may be problematic as more Java releases are made.
<headius[m]> it's too bad they were not allowed to do closed-world AOT optimization
<headius[m]> hopefully Oracle will change their position on allowing external JVM vendors to define their own AOT profiles
<nirvdrum> That's way above my pay grade.
<enebo[m]> couldn't they so long as they do not call it Java?
<headius[m]> From what I heard from Nikita, they were not allowed to have their product certified as Java if they did CWA AOT
<enebo[m]> yeah I would assume though they could have one product certified and another which was not but I know that would be confusing for them to sell
<headius[m]> yeah unclear...he was going to write something up about their experiences trying to do CWA but I have not seen anything
<enebo[m]> Pretty annoying to see Oracle do exactly what they won't allow others to do but with that said I don't know if they are claiming SVM is technically Java certified
<enebo[m]> implication perhaps though
<enebo[m]> nirvdrum: lopex you guys ever hear of LRSTAR?
<headius[m]> the claim is that it runs Java and JVM languages, so pretty strong implication
<headius[m]> of course nobody else can say they run Java unless Oracle certifies that they run Java to Oracle's satisfaction
<enebo[m]> yeah the trademark has ended hurting Java in the end much more than I thought it could
<enebo[m]> I am ignoring any extra scope here :)
<enebo[m]> e.g. beyond trademark comments
<lopex> headius[m]: yeah, prety brutal
<lopex> enebo[m]: no
shellac has quit [Quit: Computer has gone to sleep.]
<lopex> headius[m]: what if someone want to use MS* on linux then ?
<headius[m]> enebo: yeah good old Java™
<headius[m]> lopex: well I tested it on Linux and it managed to find CP950 anyway
<headius[m]> er no I tested it on Darwin
<headius[m]> but not Windows
<enebo[m]> hmm telegram may be down
<headius[m]> nirvdrum: anyway, thanks for letting me know...bummer that there's now one fewer options
xardion has quit [Remote host closed the connection]
<headius[m]> enebo: oh yeah I'm having trouble too
xardion has joined #jruby
<enebo[m]> The LRSTAR guy claims less states and faster but he then closed sourced it and went out of business
<enebo[m]> The last OSS version looks like it is windows only
subbu is now known as subbu|away
<lopex> btw have you seen this http://phrack.org/papers/jit_exploitation.html ?
<enebo[m]> is phrack.org being hosted on a hurd cluster...it loads at modem speeds
<headius[m]> IP over teletype
<enebo[m]> The image of satan at the top loaded so slowly it increased my feeling of dread
<enebo[m]> lopex: without forcing me to read this ... this is just an impl mistake causing the vuln right?
<headius[m]> interesting
<headius[m]> jlink++
<lopex> enebo[m]: like always :P
<enebo[m]> lopex: I guess that is true of new speculative vulns on intel :P
<lopex> enebo[m]: so a tandem :P
<headius[m]> enebo: fwiw only 36 non-specialized RubyObject were created, so almost all objects in a scaffolded model view are reified to some extent
<lopex> enebo[m]: I guess the new ones are still btb ones ?
<headius[m]> unclear how effectively they're reifying but that won't matter once it's adaptive
<lopex> headius[m]: for a whole rails app ?
<headius[m]> well for a single view of a scaffolded blog post
<headius[m]> might be different for other CRUD operations but I wouldn't expect the ratio to change much
<headius[m]> the RubyObject14 instances at idle all appear to be fully reified; they have null varTable
<lopex> oh per request ?
<enebo[m]> lopex: he is just dumping with visualvm occasionally to see what is being made
<nirvdrum> headius[m]: No problem. And thanks for using "fewer" instead of "less".
<nirvdrum> enebo[m]: Negative on lrstar.
<lopex> I also get slow internet outsite Poland
<lopex> locally I get whole 250Mbps I have
<lopex> on 15 year old cables
<headius[m]> there's fiber on my street now so I should probably redo my home internet
<lopex> enebo[m]: headius[m] I wonder how this ends https://www.youtube.com/watch?v=u25X8ZogRPc
<lopex> lower pings than on fiber even
<enebo[m]> lopex: I have 2 gigabit fiber providers I can get now but we have not changed yet
<headius[m]> how is that even possible
<lopex> enebo[m]: 12 tonnes of satelites https://twitter.com/elonmusk/status/1127388838362378241
<headius[m]> bbl, lunch
<lopex> headius[m]: low orbit
<lopex> headius[m]: and laser interlink
<lopex> which is 2x faster than fiber
<lopex> so all latency goes to switching
<enebo[m]> latency will suck though right?
<lopex> no
<lopex> faster than cables on aaverage
<lopex> I mean oceanic cables
<lopex> there are comparisons for different routes
<lopex> enebo[m]: east-west will be much faster due to specialized orbital planes
<enebo[m]> 550 km up
<lopex> yep
<lopex> enebo[m]: look at https://www.youtube.com/watch?v=3479tkagiNo&t=2m26s for example
<enebo[m]> lopex: my observation on this is where those satellites will downlink to
<lopex> enebo[m]: they plan a million ground stations
<enebo[m]> wired world may have a bit more flexibiltiy on routing overall
<enebo[m]> but how many will they use at once?
<lopex> enebo[m]: on end to end route ?
<lopex> I hope two
<lopex> enebo[m]: it's all directly from sats above
<enebo[m]> yeah so I beam up and it beams to new yoek but I am connecting to regional server in CA
<enebo[m]> vs complicated but much more diversely connected ISP backbones
<lopex> and I think they can split the packet on parallel routes
<enebo[m]> lopex: well fwiw for most things this will be fine
<enebo[m]> lopex: and maybe I am quibbling a bit about low latency gaming differences
<lopex> enebo[m]: they claim it will be better than cables
<lopex> and fibers
<enebo[m]> lopex: sure Elon generally claims better on all things all the time
<lopex> yeah, true
<lopex> enebo[m]: el musko :P
<enebo[m]> lopex: I will say if I am rural internet user this is pure gold
<enebo[m]> lopex: and for most users it will just be about price
<enebo[m]> lopex: assuming it works as well
<lopex> yeah
<lopex> we will see
<lopex> enebo[m]: and there's al least 3 companies wanting to do the same
<lopex> all applies fcc for thousands of satelites
<lopex> *applied
<enebo[m]> lopex: I am somewhat skeptical on latency but it is not a fardistance....if downlink is in right place it could conceivably be much faster
<lopex> I'm only saying what the claim
<lopex> *they
<lopex> enebo[m]: though I dont know what roles play fiber length and switching on latency
<enebo[m]> I wonder how long these will stay up before they burn up
<lopex> they have their own propulsion systems
<lopex> using krypton
<lopex> since xenon is 10x costlier
<lopex> lots of new info there
<headius[m]> Has anyone pushed forward with drone internet?
<enebo[m]> ok going to get some lunch bbl8r
<lopex> headius[m]: yeah, I once considered piracy on dones
<lopex> headius[m]: since drone can escape from country for legal issues
<lopex> well, is was just a fun idea
<headius[m]> I have no knowledge of the efficiency of drones at that size
<lopex> yeah, it would require mid-air refueling :P
<lopex> headius[m]: and what about maritime law ?
<headius[m]> Need to get solar drones that never land
<lopex> pirate server on international waters
<lopex> a whole new meaning
<headius[m]> It works for the scientologists
<headius[m]> Maybe they don't actually have a navy anymore but they used to
subbu|away is now known as subbu
<lopex> yeah, I recall something
KeyJoo has joined #jruby
jeremyevans has quit [Ping timeout: 258 seconds]
jeremyevans has joined #jruby
mistergibson has quit [Quit: Leaving]
KeyJoo has quit [Quit: KeyJoo]
<headius[m]> enebo: oh when I ran those reified object numbers I had the cap turned off
<headius[m]> only one case above 50, at 54, with 20 instances at idle
<enebo[m]> headius: your image before showed that one with 54 in it too
<headius[m]> yeah I just noticed that
<headius[m]> but anyway that's the only ones that were larger than 50 so it's not like there's a plague of 100-variable objects or something
<headius[m]> who knows about weirder apps with complicated models though
<enebo[m]> yeah
<headius[m]> if I always generated a new class for each Ruby type I could just install the metaclass on the class object
<headius[m]> statically
<headius[m]> but that would be madness
subbu is now known as subbu|away
<enebo[m]> I wonder if it would ever be worth having a colon2-ish name list of classes to do that too?
<enebo[m]> If the benefit really shines through having some strategic types get it done could yield something perhaps
<enebo[m]> Figuring it out dynamically is the magic all would like but we also know that even being capable of doing that makes the warmup tail that much worse
subbu|away is now known as subbu