ZAN DoYe

I doubt this memory leak occurs in lwt or it is indeed not memory leak but an implementation strategy. The minimal zero-dependency http server below can also reproduce similar 'problem'....

Occasionally, full compact gc can't recycle enough memory, after `ab` benchmark, more than 1GiB memory is occupied. This could be improved by some more intelligent strategy. We may better cc...

I tried to rewrite the server with lwt_unix, that is, without lwt_io, the memory consumption decreased very well. lwt_io uses lwt_bytes.t as its buffer, which is of type bigarray.Array1.t and...

Thanks for the explanation. Unfortunately, the performance after changing the server to use Lwt_io.direct_access is not as good as expected. I'm considering switching to janestreet async though its performance is...

Hi, @rgrinberg > The issue is indeed with Lwt_io, but it's not related to Lwt_bytes. Lwt_io has this queuing layer for "atomic" operation (see Lwt_io.primitive) that sometimes works very poorly...

build failure on debian and ubuntu is expected, the current packages of fswatch on these systems are buggy, waiting to be fixed.

[buster (oldstable](https://packages.debian.org/buster/libfswatch-dev) Thanks. I'll add the this constraint when buster is out of its lifecycle. (I hope they'll have fixed this issue by then)

https://github.com/ocaml/opam-repository/issues/22256#issuecomment-1278523088

My workaround is to set `org.eclipse.jdt.core.compiler.problem.enablePreviewFeatures=enabled` in the config file `$PROJECT_HOME$/.settings/org.eclipse.jdt.core.prefs` . coc and jdt work together smoothly with this config.

this might help, https://github.com/neoclide/coc-java/issues/131#issuecomment-1154565754