[ji] lazy loading of Java (proxy) class extensions

[kares]

• seems to work fine to the limited testing that I did locally
• the gist is - Java extensions load on demand as Java classes are (first) used
• theoretically we could also add a flag to disable the laziness and behave as before

also ... we could safely add more extensions now and do not have to worry much about bloating load times

did not run any numbers yet, but hopefully we do not do much JI internally on gem list, rake etc

[headius]

No prob, will review. Have you managed to measure anything yet?

[kares]

quick test of time bin/jruby -S gem list

# BEFORE:
 
real	0m1.823s
user	0m2.945s
sys	0m0.157s

real	0m1.778s
user	0m2.951s
sys	0m0.162s

real	0m1.769s
user	0m2.884s
sys	0m0.171s

AVG 1.79s


# AFTER 

real	0m1.739s
user	0m2.780s
sys	0m0.165s

real	0m1.736s
user	0m2.847s
sys	0m0.144s

real	0m1.712s
user	0m2.764s
sys	0m0.186s

AVG 1.73s

... gets us around 5% on my machine

[headius]

The static reference needs to be fixed, and the naming is problematic, but otherwise this seems ok. I worry a bit about races but the logic that sets up the proxy class should be safe currently. Will request review from @enebo.

[headius]

Could we use a different name for these? I find it extremely confusing when I look at the code and I see "Iterable" meaning two different things.

[headius]

Note that at this point in the code, Iterable now means three different things: the inner class, the variable, and (to me at a glance) the actual Java Iterable class. It's quite confusing.

[headius]

Same comment applies to all other such names below. I understand that it might look a bit nicer to some, but this flies against typical Java local variable naming convention.

It's somewhat confusing that the extension classes have the same names as the Java class they extend, but that seems like less of an issue to me than the local variables having yet again the same name.

[kares]

okay, will take a look into that

[headius]

This should not be static; a better place would be for it to live on the javasupport Java instance attached to the runtime.

It is weak on the value, but it also anchors a class as its key. The classes we currently extend are system-level classes, but this may be used in the future for classes loaded as part of JRuby or within extensions (e.g. jruby-openssl) that load into their own classloaders, and this reference will prevent them from being collected.

It also is not compatible with multiple JRuby instances in the same JVM, since only the first one will register (and eventually apply) an extension. The others will race to insert the extension or remove it when applying that extension.

[headius]

Oh somehow my review used an older version that was still static. I see you have fixed that, thanks!

[kares]

The static reference needs to be fixed, and the naming is problematic, but otherwise this seems ok.

✔️

I worry a bit about races but the logic that sets up the proxy class should be safe currently

exactly - its plugged in right around proxy-class initialization which is already race condition tuned (some tests are in place)

[enebo]

Seems like runtime could be a parameter here to match put().

[enebo]

It also seems to line up more with Iterable stuff below which also have runtime.

[enebo]

Seems reasonable to me. I guess only fear is proxy class initialization concurrency, but that has not actually changed at all in this PR so seems fine.