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
JIT Compiler encountered an internal limitation. EF Core Migrations. #11588
Comments
Any chance of a self contained repro? I've been trying to put together something using the bits and pieces of code you provided but so far I haven't been able to reproduce the error.
Does that mean that you have a |
No, HasData has 280 instances each one with 32 parameters ... @mikedn I just created a repository with it: https://github.com/mdmoura/JITCompilerEFCore You just need to run the command:
With that command, and with the code as it is, you will get the error:
Note: I am inserting 262 records to get the error ... But you can get the error with much less. If you comment all lines, in HasData, leaving only one then the command If you then want to create the database for that migration just run:
The SQL Database configuration is in ContextFactory. I am on a Mac so using a Docker container. But the error happens when adding the migration. Any idea what might be wrong? |
Thank you for the sample! I can reproduce the error using netcoreapp2.1 but I can't seem to reproduce it when using netcoreapp3.0. @AndyAyersMS Was there any improvement done for cases where a large number of temporary variables are created due to |
Hmm, this might have been fixed by @briansull in dotnet/coreclr#17793 |
@mikedn Is the fix included in Net Core 2.2 or only in Net Core 3.0? |
@mdmoura As far as I can tell no, the fix is not in 2.2. |
I also checked and dotnet/coreclr#17793 is NOT in .Core 2.2 sources |
@briansull Is there any way to solve this problem in the meanwhile? |
Do you really need to use nullable decimal in the initialization data (apart from those couple of values that are really null)? I would guess that even if the column is nullable EF should be able to convert from decimal to nullable decimal when inserting the data. Or perhaps use double instead of decimal, assuming that you don't end up with precision issues and that EF can convert from double to decimal. Other options:
I'd do the later, it seems preferable to keep this kind of data in a CSV file rather than in code. Even VS seems to having some problems dealing with this amount of code, it's rather sluggish when I open the file. And I wouldn't be surprised to discover that it is faster to read the file rather than to JIT-compile such code. The JIT has to generate around one megabyte of code! To try to explain a bit the tehnical issue: this code, while perhaps it doesn't look like much - a bunch of numbers, generates a very large number of local variables in the JIT. Both |
I am casting to
Yes, I am going for this one ... I was hardcoding because that would avoid to have files embedded on the class library. |
I wonder if that actually helps. I'm not exactly familiar with EF but I was looking around and I see that the migrations command generated some .cs files in a directory. And those .cs files also contain similar code. I wonder if it won't do the same thing even if the data is loaded from a file. |
If this is an ingrained pattern produced by EF tooling, we can certainly argue that Brian's fix should be ported to 2.2. So please keep us updated. I have some prototype changes lying around where the jit will reuse temps in cases like this and so avoid hitting these limitations and also emit much cleaner and smaller code, but don't recall offhand how close they were to being usable. |
Now I'm curious, how do you know when it's safe to reuse such a temp? |
However this is Fixed in .Net 4.8 |
Idea was to do something similar to what we do for the box temp: https://github.com/AndyAyersMS/coreclr/tree/OpportunisticReuseNewObjTemp |
Hmm, I don't think that handles the (hopefully very rare) corner case of a struct constructor that escapes |
@AndyAyersMS @briansull This is a pretty common pattern in EF. Can we bring this fix to shiproom for a 2.2.x patch? |
Seems reasonable -- @briansull do you want to set this up, it since it's your change? |
It would be great to have a patch, not in a far future, to solve this problem. |
Fix is in PR dotnet/coreclr#17793 and PR dotnet/coreclr#19065 |
Should have been closed by dotnet/coreclr#21493? |
Any ETA for this fix? It seems it wasn't released with Asp.Net Core 2.2.1 patch. |
It is only shipping in 2.2.2 @vivmishra any ETA for 2.2.2 ? |
@briansull - should be in early-to-mid Feb, so very soon. |
On an ASP.NET Core with EntityFramework Core I am creating an EF Migration:
The migration includes seeding 280 objects in one of the entities using HasData.
I am able to seed 1 and 20 objects but I get an exception when seeding 280 objects.
Exception
Steps to reproduce
The entity Composition is as follows:
And this is the Composition configuration:
In the code example I just posted HasData is seeding only one Composition ...
In reality I am seeding 280 compositions and I also tested seeding only 20 ...
Further technical details
The text was updated successfully, but these errors were encountered: