<headius>
so that's showing up for all generated invoker methods
<headius>
because they're not passing name in
<headius>
but if I make it pass name jossl's invokers are incompatible
<headius>
I have the InvocationMethodFactory change in a stash
<kares>
heh
<headius>
hmm
<headius>
ugh, maybe not
<headius>
I think it became such a quagmire I tossed it
<headius>
I may have an idea
<headius>
IDEA FORMING
drbobbeaty has quit [Ping timeout: 240 seconds]
drbobbeaty has joined #jruby
<headius>
cremes: lightweight fibers are being prototyped for openjdk
<headius>
they have some things working already, and the presenter told me "a couple months" they should be able to yield...once that happens, I'll make a JRuby branch that uses them
<headius>
and they're relocatable, lightweight, goal is to be able to support millions of them
<headius>
it's super exciting
<headius>
cremes: I assume you are concerned about the 100k fibers problem if you're using them in your library
akp has joined #jruby
akp has quit [Client Quit]
<headius>
this should make that go away
bbrowning_away is now known as bbrowning
<cremes>
headius: that is great news
<cremes>
thanks for the update
<headius>
I'll do what I can to move it along faster, but this will be so much better than thread-based fibers in almost every way
<kares>
:+100:
<headius>
cremes: we may also have answers coming for startup time
<headius>
openjdk+openj9 apparently already has significantly better startup than openjdk+hotspot, and there's an ahead-of-time compiler/optimizer that can help even more
<cremes>
startup time has never been a personal issue for me… most of my code is somewhat long running so startup costs are lost in the noise
<headius>
the JVM folks are finally doing everything I need
<cremes>
it’s about time they listen to you, headius! :)
<headius>
seriously!
<headius>
the curse of thread-based fibers may finally be coming to an end
<cremes>
what have they been thinking all of this time? JRuby is clearly the coolest and most important consumer of JVM goodies, so it deserves special status.
<cremes>
(I’m only slightly tongue-in-cheek with that… JRUby has lead the way with cool shit like invokedynamic)
<headius>
yeah, hopefully we can start to lead the way on these other pieces now too
<headius>
I trust I can count on you to keep us honest as prototypes start to land :-)
<headius>
maybe we'll finally become the preferred target for server-side apps
<headius>
graal, continuations, fast startup, JVM-level native library access and binding generation...it's all coming
<GitHub23>
jruby/master 1ea71f4 kares: [ji] make sure instantiation errors are propagated from Collection clone
<GitHub23>
jruby/master 7307dea kares: [ji] avoid NPE when Java collection is not clone-able (the "usual" way)...
<headius>
enebo: you got a minute to chat about this method name issue?
<headius>
ok not now then :-D bbl
<enebo>
heh
<headius>
oh hey
<headius>
enebo: so this is a problem with trying to make that field final and initialize it in all DynamicMethod constructors
<headius>
I started pulling on the thread and was able to refit everything, including generated invokers to always use the string-receiving constructor
<headius>
but jossl has been shipping its own pre-generated invokers to help startup, and they don't contain the new constructor
<headius>
so there's no way to get them to initialize that field
<headius>
and it blows up if I just blindly try to call that constructor of course
<enebo>
headius: It was a desired end goal but perhaps we just make it non-final and initialize it as much as possible and maybe initialize it to something at all in cases where we cannot change it like in old invokers
<enebo>
headius: at some compat level change we can fix the invoker and major rev jossl perhaps
<headius>
right now it's initializing to "anonymous" when not passed through the constructor, which just makes Method#inspect look a little weird
<enebo>
yeah or maybe unknown?
<enebo>
unnamed
<enebo>
:)
<enebo>
????
<headius>
we can do that but that's really the problem area...how do we do this without breaking jossl backard compat
<headius>
the answer may be that we can't, but I have a couple ugly ideas
<enebo>
well perhaps we major rev break jossl for 9.2
<headius>
that's an idea as well, and it may be fine to do that
<enebo>
we definitely do not want people using old jossl either
<enebo>
so forcing that on next significant release on our side seems ok to me?
<enebo>
so another question then is to make sure new jossl continues to work on 9.1
<headius>
the other ideas I had are 1: twiddle the Populator logic to use a thread-local to pass the name out of band along for the deprecated constructor, and 2: override getName in all JavaMethod with a writable field; only used if the final one is not provided
<headius>
right, that's why I'm skeptical about a hard rev
<enebo>
which perhaps we generate two constructors for old and new for invokers so 9.1 continues to work with newer jossl
<headius>
there's going to be a lot of grey time
<headius>
I can do that but there's no way to query if a constructor exists without causing an exception
<headius>
so jossl startup on 9.1 would immediately tank against current jossl release
<enebo>
hmm maybe we do one extra constructor check and if it works we know it is newer
<headius>
and they'd still be anonymous without one of the solutions above, which may not be a big problem
<headius>
well it's one extra constructor check for every method in jossl
<headius>
and there's hundreds if I remember right
<headius>
hundreds of exceptions raised and swallowed to find the right constructor
<enebo>
I just mean we explicitly do one and then assume the rest will be the same outcome
<headius>
it doesn't really work like that :-\
<headius>
:-(
<enebo>
heh
<headius>
if using a reflective populator, it just walks all annotated methods in a given class and for each one calls down into the invoker generator
<headius>
hmm
<headius>
I guess I could add a version number or "old style" boolean to the invoker generator interface methods
<enebo>
an invoker can have two constructors and it will naturally call the nameless one in 9.1 right?
<headius>
right now on 9.1 it calls the nameless one, yes
<headius>
my aborted patch modified it to always call the named one
<enebo>
so I am just thinking about how newer could continue to work on older release but not neccesarily solve the naming itself for 9.1
<headius>
I have not tested trying named and falling back to unnamed to see how much of a hit it really is
<enebo>
I guess we need to determine how much we need this to fully work in 9.1. It sounds like right now only a few invokers will have this extra goofy "anonymous"
<headius>
guesstimating 1-2ms for every exception trace it could add up to a good chunk
<enebo>
I am still not sure I understand why it needs exception per
<headius>
all pregenerated invokers have anonymous at the moment; with the fallback logic, only the ones in jossl would have it, plus the additional load of falling back
<headius>
Class.getConstructor does not have an exception-free path if it isn't there
<enebo>
oh I see so you are looking for new one and falling back to old one on exception
<headius>
Class.getConstructors => Constructor[] linear search might be acceptable but it penalizes proper invokers too
<headius>
right
<enebo>
interface marker perhaps?
<headius>
like I say I don't have numbers for how big a hit that would be for all of jossl, and if we rev it people can just upgrade
<headius>
ah yeah I was tossing that idea around too
<enebo>
make a new subclass or add some typing to know whether to call a new one or not
<headius>
better would be to actually add a version annotation
<headius>
I think you can query for a specific annotation without generating an exception
<enebo>
yeah I guess it depends on how often we plan on change invoker impls
<headius>
in which case no annotation would be version 0, and with annotation would start to rev as changes are needed to the interface
<enebo>
ah but yeah asking for an anno would be neat
<headius>
yeah maybe that's the way to go
<enebo>
if you ask and it is not there it is old
<headius>
class annotation on generated invokers
<enebo>
if it is then it depends on whether we ever make any more changes
<headius>
use old constructor if none, use appropriate constructor for version if present
<enebo>
yeah that sounds nice and flexible
<headius>
we've made two changes already: killing CallConfiguration and adding name
<enebo>
I also ran into this on bytelist_love
<headius>
so I think it's probably better to hedge
<headius>
ah yeah that's a third change upcoming then
<enebo>
In an aborted effort I realized psych invokers were using String and not ByteList
<enebo>
which is why I kept all those signatures the same...but in the end I think that is still a reasonable way to go as those strings are ID to me now
<enebo>
all those strings can be used to retrieve the encoded value from symbol table
<enebo>
so invokers need not change
<enebo>
but in the future if we add versioning then we could decide to change thoose
<headius>
well I'll leave that up to you, but if we do eventually decide to push BL or Symbol into DynamicMethod constsructors the annotation will be helpful
<headius>
yeah eactly
<headius>
x
<enebo>
So I am happy not changing them but this will give us a hatch if we decide to push this more
<headius>
I thought we'd determined that a raw string was insufficient to match MRI behavior because they actually do allow two methods with same bytes to have different encoded name
<enebo>
hmm yeah but we do not work right now for that either
<headius>
we do not
<enebo>
I think that might just be a limitation for now
<enebo>
and it is quite rare
<headius>
it's an edge case I'll admit...there's few practical reasons for it
<enebo>
I would argue if it is encoding.ascii? but two ascii strings methods that would just be weird
<headius>
I suppose it's possible a third-party lib might use a different encoding in a file and have a method of the same name as yours, screwing up your method's encoding
<enebo>
if two completely different encodings which happen to have same raw bytes I think that is super unlikely
<headius>
yeah there's a repro case but I forget exactly how to trigger it
<enebo>
we almost never even see non-UTF methods and nearly none that are not just ascii
<enebo>
so I think I am happy with that limitation
<enebo>
but I do wonder if this can be considered an unspecified behavior
<enebo>
just feels to weird to expect something like that to work
<enebo>
tooooooooo WEIRD
<headius>
that may be
<enebo>
actually I just tried using force_encoding and define_method and I believe it ends up eliminating ascii as every being an issue
<enebo>
since it makes a symbol and symbol creation says, yep US-ASCII
<enebo>
so it would probably only happen in weird 8 bit + sorts of common encodings
<headius>
ok, I'll look at going forward with the annotation approach and we'll look to spin a new jossl that supports both new and old signatures with "anonymous" or similar
<enebo>
coolio
<headius>
now I'll bbl
<headius>
oh good I did push my partial changes
<headius>
force_method_name
<headius>
I thought I'd lost them
<headius>
kares: ^^
drbobbeaty has quit [Ping timeout: 240 seconds]
drbobbeaty has joined #jruby
shellac has quit [Quit: Leaving]
<kares>
ok there;s still the blocker at jossl (headius was looking at) with certificates
<kares>
this prohibits doing releases as now tests also fail
claudiuinberlin has joined #jruby
<cremes>
headius: yes, when those prototypes land and you start rolling them out, i’ll help keep you honest :)