Clojurians Log v2
clojure-dev
how come tools.deps depends on a android flavor of guava? https://github.com/clojure/tools.deps/blob/cd86f78cb40f54b5dda96d322816bd391b4f16b4/deps.edn#L14
@thheller i searched about it a while ago. seems that the android is the "generic/recommended" one, and we should use the jre one only if it is required. https://github.com/google/guava/wiki/ReleasePolicy#flavors
ah, thx. so jre is the correct choice in this case. don't think tools.deps can run on android anyways
there is also a 31.1-jre version. the android version seems to be missing some stuff, at least causes https://github.com/thheller/shadow-cljs/issues/1090
31.1-jre is fine and contains the missing class
can't say if tools.deps is actually fine with the jre variant, kinda hard to find details on the differences
I'm trying to remember the details of this. tools.deps itself doesn't use it, it's a transitive dep through a maven lib or something
maven thing uses guice which uses guava, and that uses the android version
if you want a different one, make an exclusion on tools.deps for it and use whatever version you like, I'm not sure if we even use it in reality, but whatever we do it's probably minimal
yeah just wondering why its including a android version. do you happen to know which version wins in tools.deps version resolution? ie. if I specify guava 31.1-jre as a dependency on shadow-cljs. which one wins? 31.1-jre or 31.1-android?
hi there! so i was the one who opened the https://github.com/jpmonettas/flow-storm-debugger/issues/76`flow-storm-debugger`, and from my personal testing it seems that if you specify the jre version explicitly it wins over the android version, but i haven't been thorough on my testing for this particular thing since it wasn't what i was trying to figure out
meaning if guava is transitive in both cases?
{:paths ["src"]
:deps {thheller/shadow-cljs {:mvn/version "2.21.0"}
org.clojure/tools.build {:mvn/version "0.8.4"}}}I don't know
it looks like the maven lib that pulls this in actually now (in latest version) excludes guava entirely, so it probably is not even needed. I will experiment with that the next time I bump all the deps, maybe can get rid of it
Hello! Is there any plan in clojure to make it more friendly with JDK19 virtual threads?, I mean replace some synchronized methods and blocks with virtual thread friendly primitives, such chat ReentrantLock? Looking at source code, there is a very small code affected: LazySeq, Agent, Delay and AReference (witch affects some interactions with Atom and Var). Many of them only uses synchronize on this what makes is pretty easy to replace with ReentrantLock
For example Postgresql JDBC driver just https://github.com/pgjdbc/pgjdbc/commit/2668273df5a7113fa9371af24595f3138b317610 (here https://github.com/pgjdbc/pgjdbc/issues/1951 for reference).
We are migrating and experimenting on porting part of our rpc services to use virtual threads because they are pretty much all IO with DB, and the improvement is considerable, we have replaced a huge thread-pool (60-100 threads) to 8-16 (for platform threads for the virtual threads underlying pool) and the efficiency/performance improvement is pretty noticeable... (we have passed from 800req/s to 1400req/s with less memory usage (non exhaustive benchmark, but still relevant result for us)
lazyseq is by far the most common/frequent of all the things you mentioned, and giving each cell a ReentrantLock would at least double memory usage
the Java team has indicated that the synchronized limitation (being inside synchronized pins carrier threads) is a temporary limitation, and they plan on reimplementing synchronized in Java code
most LazySeq realization is uncontended
is probably temporal, they are not 100% sure of removing this limitation, but yep, you are right about the memory usage, can be important I still think we need to measure the real implications on memory usage, because the implication can be very different than the speculation. A great example is PgStatement on JDBC driver, it is also very common and they replaced the synchronization on this with a Lock instance, so we will see how it will affect memory usage in that case, In my very inaccurate tests I did not notice a real difference, I will try to do a better tests and also try with a local Clojure compiler with some synchronized blocks replaced with a lock.
We tried JDK 19 in production with --enable-preview and ran into memory leaks. There's a bug in 19.0.2 that is fixed in 20 and not yet backported. Just FYI.
@seancorfield thanks!
(there was also a different memory leak in 19.0.1 that got fixed in 20 and backported to 19.0.2 -- so I get the impression that vthreads aren't ready for production use yet: this was just with preview enabled, we weren't even using vthreads!)
yep I'm aware of it, we have plans to just experiment with it and try it on production with JDK20, in any case thanks for advice