Allow to override the 1:1 ratio between Xmx & off-heap amounts

[maxime-michel]

As discussed in deeplearning4j/deeplearning4j#8435

[saudet]

I thought we could apply this to Runtime.getRuntime().maxMemory(), wouldn't that make more sense?

[maxime-michel]

Simplifying like that you mean? It does make more sense.

[saudet]

And let's do the same for the second Runtime.getRuntime().maxMemory() too.

[maxime-michel]

Sure. I put that operation in a variable named rm in order to avoid a nested ternary operator at L485. Let me know if that works for you. Thanks!

[maxime-michel]

What about documentation, should we update the page on memory management by adding the following under Configuring Memory Limit?

-Dorg.bytedeco.javacpp.maxMemoryRatio - this allows to override the ratio by which to multiply Xmx in order to define maxBytes as well as maxPhysicalBytes, in case maxBytes and maxPhysicalBytes aren't defined. By default, 1 Xmx => 1 maxBytes and 1 Xmx => 2 maxPhysicalBytes.

[saudet]

I'm sorry, this doesn't actually work well. If we set maxMemoryRatio to something like 0.1, then maxPhysicalBytes gets 20% of maxMemory, which is likely to be hit quite often since we've given 5 times more than that to the JVM. I think we could have only 1 value for maxBytes for now and give it an appropriate name like maxBytesScale. What do you think?

Yes, we should also update DL4J's documentation there once we're done: https://github.com/eclipse/deeplearning4j/blob/master/docs/deeplearning4j/templates/config-memory.md

[maxime-michel]

Totally. Sorry about that, I'll get it fixed ASAP and submit a separate PR for documentation.

[maxime-michel]

OK, I've upgraded the PR so that:

• a 4GB instance
• with 2GB of Xmx
• and a maxBytesScale of 0.1

Would result in:

• maxBytes = 2G * 0.1 = 200MB
• maxPhysicalBytes = 2G + 200MB = 2.2G

[saudet]

I still feel this is more complexity than users should be dealing with though. Is a value like "0.1" parsed into double or something more precise? Is the scale also applied when specifying maxBytes, or not?

I think I've just had an idea about a much cleaner way to deal with that. What about adding a new "unit" like %, in addition to the usual ones like M and G? Something like maxBytes at 10% would mean 10 * Runtime.maxMemory / 100, and it would work just as well for maxPhysicalBytes with values like 150%. Very easy to read too. What do you think?

[maxime-michel]

I like that better indeed. Something like this?

diff --git a/src/main/java/org/bytedeco/javacpp/Pointer.java b/src/main/java/org/bytedeco/javacpp/Pointer.java
index 5efcaf8..e98ab73 100644
--- a/src/main/java/org/bytedeco/javacpp/Pointer.java
+++ b/src/main/java/org/bytedeco/javacpp/Pointer.java
@@ -421,7 +421,7 @@ public class Pointer implements AutoCloseable {
         }
     }

-    public static long parseBytes(String string) throws NumberFormatException {
+    public static long parseBytes(String string, long maxMemory) throws NumberFormatException {
         int i = 0;
         while (i < string.length()) {
             if (!Character.isDigit(string.charAt(i))) {
@@ -435,6 +435,7 @@ public class Pointer implements AutoCloseable {
             case "g": case "gb": size *= 1024L; /* no break */
             case "m": case "mb": size *= 1024L; /* no break */
             case "k": case "kb": size *= 1024L; /* no break */
+            case "%": size = size * maxMemory * 1024L / 100;
             case "": break;
             default: throw new NumberFormatException("Cannot parse into bytes: " + string);
         }
@@ -457,7 +458,7 @@ public class Pointer implements AutoCloseable {
         s = System.getProperty("org.bytedeco.javacpp.maxBytes", s);
         if (s != null && s.length() > 0) {
             try {
-                m = parseBytes(s);
+                m = parseBytes(s, m);
             } catch (NumberFormatException e) {
                 throw new RuntimeException(e);
             }

[saudet]

Yes, that's how I see it. Inside that method maxMemory is more like a relativeUnit than a "max" though.

[maxime-michel]

I've updated the code accordingly and pushed it. relativeUnit doesn't sound to me like a name for a variable that would hold Runtime.getRuntime().maxMemory() and then maxBytes + Runtime.getRuntime().maxMemory(), but I have no better idea so I don't mind.

I'm more concerned about tests, though. Even on master they are mostly failing on my machine. And even if they weren't, they look like black magic to me. Would you mind giving me a hand there?

[saudet]

Ah, that was it see_no_evilBy the way, did you know you can cache the Maven repository to speed up Travis builds?

cache:
  directories:
  - "$HOME/repository"

Yes, I know, it just didn't get added here like elsewhere for some reason:
https://github.com/bytedeco/javacv/blob/master/.travis.yml