Add ExecuTorchRuntime.java skeleton #11058
Conversation
Summary: No API yet. Just factor out NativeLoader.loadLibrary from Module.java and LlmModule.java, to allow mock. Differential Revision: D75180081
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/11058
Note: Links to docs will display an error until the docs builds have been completed. ❌ 1 New FailureAs of commit 1220fcb with merge base 5268b24 ( NEW FAILURE - The following job has failed:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
facebook-github-bot
added
the
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D75180081 |
|
@kirklandsign has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
kirklandsign
added
the
release notes: api
|
@kirklandsign has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
kirklandsign
changed the title
Summary: This is a partial revert of pytorch#11058. We are seeing issues with JNI loading on Meta apps. My best guess is that the call to ExecuTorchRuntime is getting optimized out in Module.java, since the result is not used. I'm re-adding the explicit load back until we get that figured out. Reviewed By: bugraoral, larryliu0820 Differential Revision: D75994546
|
@kirklandsign Some Meta apps started seeing a high load failure rate. My hypothesis is that the load might actually be getting skipped since the ExecuTorchRuntime instance may be getting optimized out of the Module call, since it's not actually used. I'm re-adding the so load in Module.java in #11385 to try to resolve this for now, but I could use your help to find the long term solution once you're back. Thanks! |
Summary: No API yet. Just factor out NativeLoader.loadLibrary from Module.java and LlmModule.java, to allow mock.
Differential Revision: D75180081