<headius[m]>
rwilliams: yeah I suppose it's worth looking into the cost of running such an organization on our own
<headius[m]>
We have also considered joining Apache or Eclipse foundations, or one of the open source host groups like Free Software Conservancy
<rwilliams[m]>
Ok. I shoot it by my lawyer, Is there a good blurb about jruby and what any donations/support would go towards, ie hosting costs, ci, etc
<rwilliams[m]>
* Ok. I'll shoot it by my lawyer, Is there a good blurb about jruby and what any donations/support would go towards, ie hosting costs, ci, etc
<headius[m]>
Not sure I have any such text handy but I could come up with something
<rwilliams[m]>
Cool.
<headius[m]>
rwilliams: sent you email
<rwilliams[m]>
Got it. Thanks
Antiarc has quit [Quit: ZNC 1.7.4+deb7 - https://znc.in]
Antiarc has joined #jruby
<rwilliams[m]>
So on curseforge, a place where many game add-on projects are hosted, the default license(first drop-down choice) for a new project is all rights reserved. There are literally thousands of add-ons that have been abandoned by their maintainers and nobody can pick them up without explicit permission from said maintainers. It's rediculous.
<headius[m]>
that's an unfortunate default
<rwilliams[m]>
Yeah
<rwilliams[m]>
I'm trying to make a fork of a WoW retail add-on for wow classic but nobody has heard from the maintainers in over a year.
<headius[m]>
enebo: so yeah continuing convo here, are your spikes on any branch right now?
<headius[m]>
after I modified StaticScope loading to use the passed-in value rather than the IRSCope field I took a step back to start looking at how we AOT the target script right now
<enebo[m]>
no that was quick tally to see how much scopeMap and _IRSCope field were not used
<enebo[m]>
and seemingly not nearly as much as I thought
<headius[m]>
currently we do still compile the target script
<enebo[m]>
but then I realized some stuff like name can trivially be ldc()s
<headius[m]>
basically it still does the full parse and compile to IR but immediately forces JIT
<headius[m]>
yeah this static scope load is like that
<headius[m]>
I had not realized we were still traversing IRScope for it
<enebo[m]>
so more or less staticscope will be a faster load than IRScope with some lazy hook to really load it
<headius[m]>
there's another angle to this too: first pass could just use full IRScope and do the parse and compile anyway, but immediately switch to jitted code
<enebo[m]>
and new AOT will do not IR stuff at all out of the gate but need to reify at some point for inliner
<headius[m]>
that's why the target script AOT works right now
<enebo[m]>
ok well that is a cool thing :)
<headius[m]>
new AOT could also still serialize IR but not deserialize it
<headius[m]>
until needed
<enebo[m]>
It has to
<headius[m]>
that would require some changes to your IR marshaler
<headius[m]>
well it doesn't have to, it could reparse or embed the source or something
<enebo[m]>
well it does if we ever want speculative opts
<headius[m]>
but we already have this
<enebo[m]>
yeah it is done already more or less
<enebo[m]>
we just store the source we make for todays AOT and we get IRScope loading
<headius[m]>
IR deserializer could probably be modified to defer the creation of instrs etc
<headius[m]>
it loads all the IRScope bits before it does the instrs
<enebo[m]>
I thought one quick way is to not boil the ocean and make a lazy getIRScope on the method then just remove consumers of IRScope in JIT until we hit all users which occur at load/startup time
<headius[m]>
the other thing I need to address from the AOT side is that the command-line AOT that serializes the IR is totally different code from the JIT AOT that runs on first script
<headius[m]>
yeah
<enebo[m]>
but I do think we can remove all runtime uses of IRScope so AOT does not him them
<enebo[m]>
It is work but not insurmountable
<enebo[m]>
and I like it from a design perspective as well. staticscipe is runtime and irscope is compiler
<headius[m]>
perhaps I should work on the front-end part this week while you keep looking at back end
<enebo[m]>
AOT is compiled and may eventually use it to inline but at that point it would again only be for compilation
<headius[m]>
specifically I will try to merge the two AOT features (full JIT code with full serialization) right now and then we can iterate from there
<enebo[m]>
I was just going to chip on removing IRScope from newclass/module/meta this afternoon
<headius[m]>
worst case we'll have AOT JVM code that still deserializes instrs but at least compiles on e.g. native-image
<headius[m]>
ok
<headius[m]>
I'll see what I can do with the AOT side then
<enebo[m]>
Making a lazy getIRScope() would be kiler because we could then just keep chipping until that stops getting called
ur5us has joined #jruby
<enebo[m]>
headius: the other thing to discuss briefly is how these AOT compiled methods are known to be loaded at startup
<headius[m]>
yeah I suppose the two big options are whole-script and per-method
<enebo[m]>
If they are registered against method tables as instances I guess they will naturally get classloaded
<enebo[m]>
ah yeah those are the two
<enebo[m]>
I have sort of thought per method in my head
<headius[m]>
I was thinking whole script since it would be easier to output all at once, but it does mean loading a large .class file when we might only want a couple methods
<headius[m]>
I could easily rig up a sort of JIT AOT right now, just dumping the bytecode for methods as they JIT and then eagerly looking for them when we define those methods in the future
<headius[m]>
that would again still do full parse+compile but go straight into jitted code
<enebo[m]>
yeah I am not sure how much benefit that would be for now vs going further to eliminate any parsing
<enebo[m]>
headius: for jaotc ultimately we want the planet compiled so it mmaps in but then we probably only want to use a subset?
<headius[m]>
those class files could probably be AOT as well but yeah I am not sure how much benefit
<headius[m]>
well I know that JVMs don't verify bytecode for a method until it'ss called
<headius[m]>
so they are deferring some amount of processing
<headius[m]>
this would support a whole-script AOT
<headius[m]>
for jaotc I'm not sure...it works with class files and jars
<enebo[m]>
but wasn't one benefit of jaotc that there is no load verfication?
<headius[m]>
I think it mostly just C1 compiles everything and then includes that in an executable so it can be used immediately instead of going to interp
<headius[m]>
I'm not sure about that
<headius[m]>
the metadata/verification thing
<headius[m]>
clearly CDS does that
<headius[m]>
and they still have CDS as a separate project
<enebo[m]>
sorry shit...I meant appcds :(
<enebo[m]>
haha
<headius[m]>
ah ok
<enebo[m]>
not jaotc
<headius[m]>
yeah for appcds it might not matter full script or individual methods
<enebo[m]>
(hence talking about mmap)
<headius[m]>
it's just going to take all the classes we give it and pre-verify them into some mmap jumble
<enebo[m]>
yeah so long as those classes exist it is more a matter of knowing we should use that compiled class and not parse
<headius[m]>
CDS may make both about the same as far as boot time, so then it would be more a question of memory/metaspace at runtime
<enebo[m]>
yeah but compared to parsing+building+(and optionally+JITTing) it should help startup
<headius[m]>
yeah either way it should help once we have AOTable code that has minimal IR boot overhead
<enebo[m]>
I am hoping for that at least :)
<headius[m]>
enebo: changing gears for a moment...who did you talk to about the vhost thing for rubygems-proxy?
<headius[m]>
if we can't have that switched today I'd be fine just running it on my server so we can say it's up
<enebo[m]>
headius: bob. I just pinged him about it
<headius[m]>
ok
<enebo[m]>
headius: anyone else .... mavengems.jruby.org should be pointing properly now