10:23 <kares[m]> I am close to finishing java_class refactoring but I managed to hit another threading issue with an unfinished Java proxy (there's a few more to eager to initialize such as java.lang.Class for JavaClass compatibility). confirmed it's a bug with the 'emulated' ClassValue map + unfinished proxy tracking -> there's still a chance ending up with 2 proxies for the same class.

10:23 <kares[m]> https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/util/cli/Options.java#L82

10:23 <kares[m]> 'normal' Java ClassValue backend works, I wonder if we can just flip the switch at this point?

10:57 <nonlandi[m]> <headius[m] "that is the right place for the "> Thank you for the update! :)

14:21 <enebo[m]> kares: I think so. You still plan on fixing the bug? It sounds like a) we could determine whether there is enough warmup/startup impact of having that on by default and it not much then just only run with that b) you fix the bug and we determine whether to flip it off

14:22 <enebo[m]> kares: We would like to get everything for 9.3 in as early as possible too to figure out if any other issues are lurking. So landing sooner and fixing that bug later seems like a reasonable option to me

14:24 <kares[m]> been looking at it today morning - got a vagua understanding but not sure why it happens with a class map but not using class-value

14:24 <kares[m]> at this point I am not sure whether it is present in current version - likely - it's just that the class proxy initialization is different due the JavaClass deprecation that might expose this.

14:24 <kares[m]> really want to fix this before landing - I do not like that we would have 2 java.lang.Class proxy instances around in some cases ...

14:25 <enebo[m]> kares: ok

14:29 <enebo[m]> kares: I am a little confused though. if we enable the indy support you will not have two proxy instances. This would allow the rest of your work to be tested until you figure out the non-indy proxy problem. Feels like there would be some value to getting the rest of your refactoring on master?

14:29 <enebo[m]> kares: If you are close I guess I don't see there being a lot of value but I am just throwing it out there

14:32 <kares[m]> that's what I am seeing atm ... yes - with a proper ClassValue backend the identity tests pass

14:34 <enebo[m]> kares: when I said "tested" I mean in potentially wider circulation from anyone who runs their projects against jruby-head on CI (as an example). Just in case that was not clear

14:57 <headius[m]> definitely need to fix but there is no reason the non-ClassValue version couldn't be made safe

15:18 <headius[m]> kares: may not be any value in keeping the non-Java7 version around but did you try using computeIfAbsent in the Map-based one?

15:18 <headius[m]> https://gist.github.com/headius/88a0f3f534e0f64f8cb234bb7567438a

16:05 <kares[m]> it's on the same thread - we're setting up a proxy class and while triggering dependencies we end up setting up the same proxy again

16:08 <headius[m]> Oh I see

16:09 <headius[m]> But if the standard ClassValue works then there must be a way to make the regular one work

16:10 <headius[m]> regular meaning our map version

16:10 <headius[m]> The JDK version isn't magic

16:11 <headius[m]> My only concern going to the jdk version is that leaking

16:11 <headius[m]> But our version isn't weak so I'm not sure how we're avoiding it if it actually was a problem

16:16 <kares[m]> yy should work - it's simply that I had other plans thus my initial complain 😜

16:18 <headius[m]> Yeah I am fine ditching our version if we can be sure the JDK version doesn't leak (any more than ours)