Thanks for reviewing! You're quite the savior of this branch :)
On 27.01.2021 11:02, Johan Corveleyn wrote:
> was wondering what you meant by "This error is easily seen
> when running JavaHL tests"
If you checkout r1882518, tests die with 'Bad global or local ref passed
to JNI' before this error can be seen. However, if you also cherry-pick
r1882522 on top to fix this problem, that's where you'll see 'JNI call
made with exception pending' that I fixed in r1882520.
Sorry for confusion. I edited/reordered patches a few times before
committing, and didn't notice that the commit message is not too good
with this ordering.
Which brings me to next question. In other replies, you suggested that I
make some edits in code and also amend commit messages. How do I do that
in SVN? I understand that unlike git, a submitted branch is already set
in stone? Please advise. This branch is my sole SVN experience in entire
life, so I'm quite a newbie. I did google and ask another guy, though,
to no avail.
> I do get 8 warnings with this sort of message (always similar
> stacktrace, always coming from UtilTests.testFileMerge, line 120):
> [[[
> WARNING: JNI local refs: 33, exceeds capacity: 32
> at java.net.NetworkInterface.getAll(java.base@11.0.6/Native Method)
> at
java.net.NetworkInterface.getNetworkInterfaces(java.base@11.0.6/NetworkInterface.java:359)
To my knowledge, this is an oversight in
'java.net.NetworkInterface.getAll' itself.
JNI documentation says [1]:
[[[
You can call the JNI EnsureLocalCapacity() method to tell the JVM that
you'll be using more than 16 local references. This allows the JVM to
optimize the handling of local references for that native. Failure to
inform the JVM can lead to a FatalError if the required local references
cannot be created, or poor performance that's due to a mismatch between
the local-reference management employed by the JVM and the number of
local references used.
]]]
I'm observing the same warnings in other Java programs which are
unrelated to SVN. I think that this can be ignored for the purposes of
this JavaHL related discussion.
[1] https://developer.ibm.com/languages/java/articles/j-jni/
