-
Notifications
You must be signed in to change notification settings - Fork 173
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
Support GraalVM 22.0 #63
Comments
You'll need to update the version of the plugin in the pom.xml file as well. |
Actually, it looks like we need to add a couple of allowUnsafeAccess to the config files, see oracle/graal#2694. Please give it a try! |
I added a feature
But it doesn't help. Do you know where bytedeo uses these unsafe calls? |
For JavaCPP itself, it's all in the That's not something we can set at runtime, it's something that needs to be set at build time. |
The issue seems to be that GraalVM has problem analyzing Unsafe method calls from JNI c/c++ code, which are triggered by Does JavaCPP generate c/c++ code that calls Unsafe methods? |
No, but I don't think this is issue. If that fixes it though, please open a pull request to that effect. |
@saudet I'm running in to this as well. I tried adding the relevant allowUnsafeAccess to all the raw indexers and I still seem to get the same error. Do you know if we might need to add this to any presets that potentially use the RawIndexer? I looked at a relevant netty fix and they seemed to just disable their unsafe mechanism. I'm wondering if we might need to do something similar in javacpp? I've also tried attaching a debugger to the native compilation process and my understanding is that they now do substitutions for any unsafe calls then that seems to throw the error. The unimplemented error itself I'm not sure about. It could either be unimplemented behavior for unsafe in graal itself or maybe it's just noise. For context, I'm trying this on java 11 and 17 graalvm 22 as well. |
… Native Image 22.x (issue bytedeco/sample-projects#63)
Indeed, it looks like it doesn't like it anymore when we have anything related to sun.misc.Unsafe in the config files, so I've tried to strip that out, and that fixes the compile error, plus I can still access sun.misc.Unsafe! Well, whatever, I've pushed that in commit |
@saudet thanks. Looking at this further it appears the same problem happens with graalvm 21.3 as well. I'm going to try to go down the versions at least to see when this all was triggered. Edit: I get a different error on 20.x so it's from 21.3 at least not just 22. |
Still seeing this even with snapshots:
I think the source might be the UnsafeIndexers. The fix I saw in netty was to make it optional: netty/netty@ff3858d Not sure if it's possible to disable unsafe usage in the indexers or not. For completeness, here's how I attempted to allow unsafe access for all the indexers:
In the mean time I'll keep digging through the 21.x release notes to see what's going on. I'm now wondering if maybe there's an indirect change that makes this happen. My hunch is this still might have something to do with their substitutions. That's what it keeps referencing in the errors. I wonder if their unsafe implementation is still incomplete? In their PR where they supposedly fixed this issue they missed a few. |
You need to make sure that all the JSON files you pass to it do not contain "Unsafe" anywhere. How are you making sure of that? |
I'm manually configuring the file paths. Let me get rid of all declarations. |
I'm telling you, it works here. I can't fix what isn't broken! You'll need to give me something that doesn't work if you want me to debug it. |
Yeah of course. Let me see if I can debug this on my end and narrow this down. I was just posting the main part of the project I was specifically focusing on wrt unsafe and javacpp. Without changes everything worked before 21.x and worked on 20.x. I'm not expecting some magic here :) - I've also cloned javacpp and might try to see if removing unsafe helps. It's a fairly easy theory to test since everything's optional. If it works I'll submit a PR and you can coach me through how you might want to design a fix around it if the solutions is good enough. Otherwise I'll keep trying to narrow this down. Edit: Ok that clearly didn't work. Let me try rerunning the generator. |
@saudet feel free to close this issue. In the scope of this project it does work. Of note I also had to update the native plugin to:
|
The fix for this has been released with JavaCPP 1.5.8. Thanks for reporting! |
Hi,
I wan't able to compile
opencv-stiching-native
with latest GraalVM 22.0. Is there a plan to support that?Following is part of the errors I got. Do you have any idea what these errors are? Can they be fixed by configuring GraalVM?
The text was updated successfully, but these errors were encountered: