Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2023-02-24

Channels

#clojure-dev
<
2023-02-24
>
souenzzo09:02:02

@U05224H0W 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

thheller09:02:10

ah, thx. so jre is the correct choice in this case. don't think tools.deps can run on android anyways

thheller15:02:48

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

thheller15:02:08

31.1-jre is fine and contains the missing class

thheller15:02:08

can't say if tools.deps is actually fine with the jre variant, kinda hard to find details on the differences

Alex Miller (Clojure team)15:02:23

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

Alex Miller (Clojure team)15:02:48

maven thing uses guice which uses guava, and that uses the android version

Alex Miller (Clojure team)15:02:49

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

thheller15:02:28

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?

João Pedro de Amorim Paula19:02:27

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

thheller15:02:03

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"}}}

Alex Miller (Clojure team)15:02:24

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

👍 4
niwinz15:02:58

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).

niwinz15:02:06

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)

ghadi16:02:36

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

ghadi16:02:37

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

ghadi16:02:26

most LazySeq realization is uncontended

niwinz16:02:57

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.

seancorfield17:02:29

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.

seancorfield17:02:36

(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!)

niwinz00:02:16

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