Adam Pocock

@lyubortk Are you observing this leak in real code? When running the example in VisualVM for a fixed number of iterations the heap ends up clean after those iterations have...

Looks like valgrind found some issues in the C API, and as only TF Java and TF Go use that, they might not be checking for it in regular TF...

Ok, we'll see what they say in about the leaks valgrind found in the C API. Seems like the problem (or at least some of the problem) is there.

Try the latest snapshot, we fixed a leak in the saved model bundle in it. Otherwise what jdk and GC algorithm are you using? There's a known issue with JavaCPP's...

Are they dying due to the JVM throwing `OutOfMemoryError` (either from JavaCPP or the JVM itself), or because k8s decided that pod was over the memory limit? Also it sounds...

> > Are they dying due to the JVM throwing OutOfMemoryError (either from JavaCPP or the JVM itself), or because k8s decided that pod was over the memory limit? >...

Could you describe your issue in more detail (e.g. trigger for the leak, size of it, which JVM, platform, any JVM GC configuration parameters)? The first issue mentioned in this...

Did you get any logs or errors out of the `TensorFlow.loadLibrary` call? We have tried to make TFDF work before, but there was a bug in it which means it...

Hmm. Well that symbol has been in TF for years, so it's not new enough that we're missing it. Maybe it's not exported from our build of the native libraries?...

Fine by me, CentOS 7 is 8 years old at this point. The next step would be CentOS 8 but after Red Hat killed it it hasn't seen a lot...