You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -147,11 +147,11 @@ vectorscan4j provides utility methods for serializing and deserializing a Databa
147
147
148
148
## Incorrect Usage Patterns
149
149
150
-
There is a number of things to watch out for in terms of how to use the wrapper which can lead to memory leaks, undefined behavior, or break the JVM.
150
+
There is a small number of niche things to watch out for in terms of how to use the wrapper which can lead to undefined behavior, or break the JVM.
151
151
152
152
### 1. Not closing Database / Scanner objects
153
153
154
-
Database- and Scanner objects both hold native memory. Calling close() on those objects will clean the native memory
154
+
Database- and Scanner objects both hold native memory, i.e. memory that is not managed by the JVM Runtime. Calling close() on those objects will clean the native memory
155
155
that they are holding. This memory will *also* be freed if one doesn't call the close() explicitly. However, in
156
156
that case it will only happen when the Database- or Scanner object gets garbage collected (which might be far in
157
157
the future).
@@ -165,9 +165,8 @@ the future).
165
165
// -> Its native memory gets freed, but not immediately.
166
166
}
167
167
```
168
-
This might still be a problem, as the garbage collector might not get called for a long time (because the bulk of the
169
-
data was lying off-heap, so the JVM doesn't see any memory issues).
170
-
Thus, the easiest and safest usage pattern to ensure that memory doesn't accumulate is through a try-with-resources-block:
168
+
For more optimal memory usage, either manually close Database and/or Scanner objects by calling the close() method,
169
+
or initialize them with a try-with-resources-block:
171
170
```java
172
171
// This function is safe to call
173
172
void createDbSafe() {
@@ -223,8 +222,8 @@ This is due to how the Foreign Function & Memory API handles exceptions thrown d
223
222
224
223
### 4.Using the same Scanner concurrently in multiple threads
225
224
226
-
AScanner object maintains an internal scratch space, which is not safe to use in multiple threads.
227
-
Using the same Scannerconcurrently leads to undefined behavior.
225
+
AScanner object maintains an internal scratch space, which is not safe to use from multiple threads.
226
+
Using the same Scannerfrom multiple threads will throw a VectorscanException.
0 commit comments