[mono] Add DISABLE_NONBLITTABLE for non-blittable marshaling #46444
Conversation
CoffeeFlux
requested review from
lambdageek,
marek-safar,
thaystg and
vargaz
as code owners
|
Tagging subscribers to this area: @CoffeeFlux Issue DetailsThis flag is not set by default on any platforms, but long-term it should be useful on wasm with the pinvoke generator work being done by the interop team. This flag reduces around 13k in dotnet.wasm as of today (12/29/2020). However, that is a fairly low-end measurement because this PR only focused on the pinvoke marshaling rather than the full functionality. The structure of our marshaling callbacks means that even with icall linking, a lot of marshaling code will be kept around and unused, including all the string marshaling. To solve this, we can either give up on the ilgen functionality being in a separate library so it gets linked our normally or we can just have this flag cover marshaling functionality as a whole. I've split that part off into a followup PR since it's more likely to be contested, but I implemented the latter option (and also disable things like certain JIT icalls for the same reason). We also will want analyzers set up before this is useful, so hopefully this solution is fine in combination with an extra analyzer for the marshaling methods in question? We also need to finish converting the libraries over to function pointers where appropriate (see 839b134 for an example).
|
|
Tagging subscribers to this area: @CoffeeFlux Issue DetailsThis flag is not set by default on any platforms, but long-term it should be useful on wasm with the pinvoke generator work being done by the interop team. This flag reduces around 13k in dotnet.wasm as of today (12/29/2020). However, that is a fairly low-end measurement because this PR only focused on the pinvoke marshaling rather than the full functionality. The structure of our marshaling callbacks means that even with icall linking, a lot of marshaling code will be kept around and unused, including all the string marshaling. To solve this, we can either give up on the ilgen functionality being in a separate library so it gets linked our normally or we can just have this flag cover marshaling functionality as a whole. I've split that part off into a followup PR since it's more likely to be contested, but I implemented the latter option (and also disable things like certain JIT icalls for the same reason). We also will want analyzers set up before this is useful, so hopefully this solution is fine in combination with an extra analyzer for the marshaling methods in question? We also need to finish converting the libraries over to function pointers where appropriate (see 839b134 for an example).
|
|
nit: the |
Do we have an issue tracking/requesting this feature? |
|
I think some of them are a bullet point on the pinvoke generator issue, but I need to go through and open separate issues about the ones we need. |
CoffeeFlux
force-pushed
the
disable-nonblittable
branch
from
7da8f95
to
5351c93
Compare
CoffeeFlux
changed the title
This flag is not set by default on any platforms, but long-term it should be useful on wasm with the pinvoke generator work being done by the interop team. This flag reduces around 13k in dotnet.wasm as of today (12/29/2020). However, that is a fairly low-end measurement because this PR only focused on the pinvoke marshaling rather than the full functionality. The structure of our marshaling callbacks means that even with icall linking, a lot of marshaling code will be kept around and unused, including all the string marshaling. To solve this, we can either give up on the ilgen functionality being in a separate library so it gets linked our normally or we can just have this flag cover marshaling functionality as a whole. I've split that part off into a followup PR since it's more likely to be contested, but I implemented the latter option (and also disable things like certain JIT icalls for the same reason). We also will want analyzers set up before this is useful, so hopefully this solution is fine in combination with an extra analyzer for the marshaling methods in question?
CoffeeFlux
force-pushed
the
disable-nonblittable
branch
from
5351c93
to
ead492e
Compare
ghost
locked as resolved and limited conversation to collaborators
This flag is not set by default on any platforms, but long-term it should be useful on wasm with the pinvoke generator work being done by the interop team.
This flag reduces around 13k in dotnet.wasm as of today (12/29/2020). However, that is a fairly low-end measurement because this PR only focused on the pinvoke marshaling rather than the full functionality. The structure of our marshaling callbacks means that even with icall linking, a lot of marshaling code will be kept around and unused, including all the string marshaling.
To solve this, we can either give up on the ilgen functionality being in a separate library so it gets linked our normally or we can just have this flag cover marshaling functionality as a whole. I've split that part off into a followup PR since it's more likely to be contested, but I implemented the latter option (and also disable things like certain JIT icalls for the same reason). We also will want analyzers set up before this is useful, so hopefully this solution is fine in combination with an extra analyzer for the marshaling methods in question? We also need to finish converting the libraries over to function pointers where appropriate (see 839b134 for an example).