Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document the performance cost of local/global refs creation #65

Closed
mboes opened this issue May 15, 2017 · 2 comments
Closed

Document the performance cost of local/global refs creation #65

mboes opened this issue May 15, 2017 · 2 comments

Comments

@mboes
Copy link
Member

mboes commented May 15, 2017

The JNI defines two types of object references: local references (only valid in the current thread, dies at the end of current call frame) and global references (globally valid, GC controlled lifetime).

The jvm package, like jni, currently always creates local references. But objects with local references are hard to handle: need to make sure they don't get shared with other threads, and need to make sure the local reference gets discarded eventually (i.e. doesn't leak). Types might help dealing with local references safely, but this can have a big impact on API's and on the ease of writing bindings. Global references have a major advantage: we can treat global object like any other Haskell value: create it, and then largely don't worry about its lifetime (the GC will take care of it).

We could in theory create global references always, removing the local references handed to us by default by the JNI. Is this viable? It depends on the performance cost. If there are no performance implications, then there is great value in forgetting about local references altogether (no impact on API's, no lifetimes to worry about...). If the performance gap between local and global references is noticeable but not too large, then it may still be worth it to create global references by default and then optimize them away in special cases.

tl;dr: designing a proper solution to #7 requires data. Which design point is the best compromise will depend on the data.

@facundominguez
Copy link
Member

The analysis of this issue needs to consider the effect of delegating to the Haskell GC the disposal of global references.

By now we have experienced in practice that the Haskell GC has no pressure to collect global references when the Java heap needs it urgently.

The benchmarks show that creating 200 local references takes as long as doing a method call with JNI. 10 global references with attached finalizers can be created in the same time. Maybe in some scenario where the workloads and the GC passes can be coordinated, global references would be an option. But it doesn't look clearly as the best default.

@facundominguez
Copy link
Member

@mboes, do you want to explore any other alternatives? We could close the ticket otherwise.

@mboes mboes closed this as completed Feb 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants