lucerne has quit [Quit: Ping timeout (120 seconds)]
lucerne has joined #jruby
lopex has quit [Quit: Connection closed for inactivity]
<headius> enebo: my two issues should be fixed and merged to master
<headius> we are on the release 0.1.0 so that differs from the 2.6.8 hacked version, but I have filed all the appropriate bugs for that
<headius> er of ostruct
sagax has joined #jruby
<headius> good morning
<headius> I don't think ruby-core is going to change anything
<headius> basshelal: I have released jnr-ffi 2.2.7 with just the ASM update
<enebo[m]> bleh this is pretty annoying
<headius> whats up
<enebo[m]> I just tried putting org/jruby/ into shaded source and then reverted but then realized it is merely because the compiler is assuming Java 1.6
<enebo[m]> So that hack might work but how do I change that in pom.rb.
<enebo[m]> core does it but then it basically explicitly has execute_goals
<headius> why do we need a java source in there? The Sonatype page made it sound like a README would be sufficient
<enebo[m]> here is an example of the error:
<enebo[m]> we need it because we need a javadocs.jar for complete to see
<enebo[m]> sources is fine with the readme-like stuff
<headius> perhaps we could put a bogus package with a package-info.html in it?
<headius> I see the module error, is that what you mean?
<enebo[m]> please add one and see because I definitely hate the notion of putting a bogus .class into our jar
<headius> agreed
<enebo[m]> the module error I think is partially from the previous error
<enebo[m]> where it cannot compile
<headius> ok
<enebo[m]> at least I think the module error is because it aborted making core
<headius> yeah it should be set to Java 8 at least
<headius> how do I repro this to test package info?
<headius> oh just like CI perhaps
<headius> actually... -Prelease?
<headius> confirm that produces a javadoc jar?
<enebo[m]> well I have been doing a full release to sonatype
<enebo[m]> Actually I can just try this since Iam already doing this frequently
<enebo[m]> maybe...I did something earlier where it made something but it was empty and it then aborted from that
<enebo[m]> don't recall if that was sources or javadocs
<headius> hate to admit but I have never made one myself
<enebo[m]> so maybe org.jruby.sonatype/package-info.html
<headius> yeah I don't have any strong opinion about the name
<enebo[m]> ah .java but if I do that it may try compiling it
<headius> org.jruby.doc or javadoc or core or shaded?
<headius> well it doesn't actually compile, only in javadoc
<enebo[m]> hopefulyl then maven compiler ignores it
<headius> it should, it has been around forever
<enebo[m]> ok well I can try it
<headius> oh you mean for purposes of java 1.6 vs 8
<headius> yeah good question
<headius> and you don't want to add a compile plugin config because it isn't really compiling anything
<enebo[m]> I haven't added anything but it will run all the default phases
<enebo[m]> just trying with older package-info.html
<headius> ok I got confused because all the articles talk about .java now
<headius> yes html would be the safer option
<enebo[m]> I believe we should get help with maven and hopefully kristian because I am not sure if anyone else understands the pom.rm -> xml syntax
<enebo[m]> but if this works then great for releasing
<headius> yeah I am willing to spend a few days to a week after 9.3 settles to try to make some sense out of this
<headius> I don't think we can rely on mkristian for help
<headius> enebo: did that work?
<enebo[m]> headius: nope. mvn ran to completion but sonatype close failed
<enebo[m]> "Missing: no javadoc jar found in folder '/org/jruby/jruby-core/'"
<enebo[m]> I think the right solution for this problem is to set shadedSource location which may then also generate javadocs
<enebo[m]> It was the first thing I readabout when I was trying to figure this out so maybe I will circle back to it
<headius> sonuva
<headius> yeah I guess just do that then
<headius> if that works then it will include our sources and javadocs and we can be done with this
<enebo[m]> just do that...easier said than done but it makes sense that a shaded artifact could still have docs with shaded substitutions
<headius> enebo: I think we need to spend time on deoptimization before finishing inlining
<headius> if we could deoptimize we could optimistically assume all method calls don't need frame and a lot of code would be much faster
<headius> this ostruct alias thing has just got me thinking again about how to lazily allocate frames and scopes
<enebo[m]> yeah I suppose since it is different code they can be in any order
<headius> lazy frame allocation would be a big last mile for our optimizations
<enebo[m]> how many methods conditionally need a frame field vs always needing one
<headius> inlining blocks being the last last mile
<headius> (or splitting/specialization which is the same thing)
<headius> the biggest offender of framing is [] because of String#[] doing $~ stuff
<enebo[m]> yeah and $_
<headius> alternatively figuring out a way to lazily prep $~ would be a monster gain
<headius> I don't know of a way to do that without enter/exit frame marking somewhere though
<enebo[m]> I like the notion of deopting since it needs to happen to get literal blocks inlining without basically emitting a guard which kills opts results
<enebo[m]> kills is strong
<headius> a frame depth counter would work but I dunno how much it saves us over just pushing and popping frame the way we already do
<enebo[m]> but it makes our passes not work since we have two paths
<headius> the back and forth to TC is the main hit
<headius> if we could do it lazily somehow then we'd just have a special call site that lazily preps $~ if needed and no frames would be forced
<headius> so that might be an easier pill to swallow but full deopt would solve it and everything else
<enebo[m]> the over cost of deopt is more expensive as a general opt than lazy one-off too but I am not so worried about that
<headius> in theory branching from JIT without frame to Full with frame should be a one to one match but there is a bunch of state to carry over
<headius> so it would be throwing a deopt exception that captures all locals and an IP and the catch block invalidates the jitted method and calls into interpreter with those locals and IP
<headius> all live locals at the point of call would need to be passed into the call site
<enebo[m]> yeah all locals and all temps and a map of temps which have been removed back to what values they should be
<headius> yeah I am including temps when I say locals... all live variables at that point in their slots
<headius> with indy some of this metadata could be included without adding bytecode but the values themselves would have to be pushed into the call
<headius> i.e. we encode a call to [] as []{slot1, slot4}(arg1, arg2, arg3, temp1, temp4)
<headius> this is similar to how we'd encode kwargs, really
<headius> FWIW I do try to detect whether [] is being used with a literal non-regexp but if it's an opaque variable I cannot tell
<headius> like if you do str[5] I do not mark it as frame-aware
<headius> the remaining jnr projects have been updated to track the new jnr-ffi with asm 9.2
<enebo[m]> well my latest hack for maven was to just copy java-base- (and .asc) to target of core. maven does not just look for files so it ignores that
<headius> hah gross