Add a registry of native peers about jni-rs HOT 5 OPEN

Did you consider, as a possible solution, the usage of generation-based (also known as versioned) pointers? This seems like a possible (and possibly efficient) solution to the issue.

For more information, please take a look at the slotmap crate.

from jni-rs.

Did you consider, as a possible solution, the usage of generation-based (also known as versioned) pointers? This seems like a possible (and possibly efficient) solution to the issue.

No, have not had a change to use them. Are they supposed to be significantly more efficient than, say, a proper concurrent hash map, allowing both concurrent reads and writes?

Our present code uses a simple mutex-protected HashMap, but we consider using a concurrent hash map. However, this feature is mostly oriented at developers working on the project to catch bugs during development early, so performance is not an issue.

from jni-rs.

Are they supposed to be significantly more efficient than, say, a proper concurrent hash map, allowing both concurrent reads and writes?

I would say they can be more efficient, but benchmarking is the ultimate answer.

from jni-rs.

Q0: Is it useful to all users?

Given our experience in EJB; some feedback from people who got this wrong; and the feedback from our tutorial project, I think yes, it shall be added, either as a sister crate, or as a module within this crate.

A battle-tested implementation already exists in EJB under Apache 2.0, so we can pull it from here, with an appropriate notice on 3rd-party code.

from jni-rs.

I'd appreciate something like this honestly. It definitely would make things safer / easier when dealing with native pointers. Having a way to manage this from the Java side is very attractive, as it's likely much faster and "native"

from jni-rs.