Home Dashboard Directory Help
Search

Large Object Heap (LOH) does not behave as expected for Double array placement by OmegaMan


Status: 

Closed
 as By Design Help for as By Design


6
0
Sign in
to vote
Type: Bug
ID: 266330
Opened: 3/30/2007 7:48:32 AM
Access Restriction: Public
0
Workaround(s)
view
5
User(s) can reproduce this bug

Description

The Large Object Heap is used when any large object/arrays exceed over 85K. With that knowledge one can predict/map which generational heap a structure will be placed at. For example since a byte in .Net is one 'byte' in size, one can create an array of bytes such as

byte[84987]

which will belong in the Generation 0 and not be placed in the LOH. But if one creates an array of bytes such as

byte[84988]

That will be placed on the LOH. The same can be done for most all of other base types:

byte[84987] placed into generational heap 0 , larger allocations in the LOH - heap 2
int[21246]    placed into generational heap 0 , larger allocations in the LOH - heap 2
float[21246] placed into generational heap 0 , larger allocations in the LOH - heap 2
char[42493] placed into generational heap 0 , larger allocations in the LOH - heap 2
decimal[5311] placed into generational heap 0 , larger allocations in the LOH - heap 2

The base byte size of the item dictates how large the array must be and those values shown above are as expected.

But the a double intrinsic of eight bytes should break around 10600 but it doesn't...it breaks at 1000. So when testing the double array:

double[999] placed into generational heap 0 , larger allocations in the LOH - heap 2

This is not expected. Why does double fall even shorter than what Decimal, size 16, does?
Details
Sign in to post a comment.
Posted by Microsoft on 4/4/2007 at 4:04 PM
The reason why double arrays are allocated on the LOH is because of performance. The LOH is alligned to 8 bytes so access to 'big' arrays is much faster if it is allocated on the LOH. We determined that the best tradeoff is when the array is bigger than 1000 elements.

Feel free to contact me directly if you have any other question.
Thanks
Claudio Caldato
CLR Performance & GC Program Manager
claudioc@microsoft.com
Posted by Microsoft on 4/1/2007 at 11:30 PM
Thanks for your feedback. We have reproduced this bug on Visual Studio 2005 SP1, and we are sending this bug to the appropriate group within the VisualStudio Product Team for triage and resolution.

Thank you,
Visual Studio Product Team.
Posted by Microsoft on 3/31/2007 at 10:46 PM
Thank you for your feedback. We are currently investigating. If this issue is urgent, please call support directly (see http://support.microsoft.com).

Thank you,
Visual Studio Product Team
Sign in to post a workaround.