You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This leftover issue is created to follow up the discussion at #13315 (comment) when implementing the struct support in downcall.
Technically, we should be able to return the same ffi_type for the same structs instead of creating duplicate ffi_types. e.g.
struct A {
int a1;
int a2;
}
struct B {
int x;
int y;
}
One of the challenges in this optimization is how to deal with the nested structs correctly under such circumstances. e.g.
struct A {
int a1;
int a2;
}
struct B {
int x;
struct C { <------- struct A and C share the same ffi_type
int c1;
int c2;
}
}
In addition, we probably need to ensure that the same the ffi_type for structs is shared in multithreading given these ffi_types are only released when JVM exits. That being said, we need to figure out a smart way to cover all cases to get it working to meet our anticipations.
I will need to create a couple of test case as above to go through in the existing code in debugging to better understand how everything with ffi_type is set for native signature before proposing any solution.
This leftover issue is created to follow up the discussion at #13315 (comment) when implementing the struct support in downcall.
Technically, we should be able to return the same
ffi_type
for the same structs instead of creating duplicateffi_types
. e.g.One of the challenges in this optimization is how to deal with the nested structs correctly under such circumstances. e.g.
In addition, we probably need to ensure that the same the
ffi_type
for structs is shared in multithreading given these ffi_types are only released when JVM exits. That being said, we need to figure out a smart way to cover all cases to get it working to meet our anticipations.FYI: @tajila, @pshipton
The text was updated successfully, but these errors were encountered: