Large Object Heap

  • Thread starter Thread starter eschneider
  • Start date Start date
E

eschneider

When determining the size of the object for the LOH, I assume that sub
objects (like Address in the Person class) are excluded?

class Person

string NameLast
string NameFirst
Address AddressHome
Address AddressWork

end class

class Address
string Street
string State
string City
string Zip
end class

Thanks,

Schneider
 
eschneider said:
When determining the size of the object for the LOH, I assume that sub
objects (like Address in the Person class) are excluded?
They're not, but of course reference types only count as 4 bytes (or 8 bytes
if you're 64-bit). The LOH size determination doesn't recursively walk the
object structure to add up sizes, if that's what you mean. Indeed, since
those sub-objects could be shared, that would yield wrong results.
class Person

string NameLast
string NameFirst
Address AddressHome
Address AddressWork

end class

class Address
string Street
string State
string City
string Zip
end class
Only the individual strings would be candidates for the LOH; the Person and
Address instances never are because they're far shy of the 85,000 bytes
threshold. And it's also pretty unlikely that you'll have strings bigger
than 85K...
 
Ok, but you point is they do count for something (4 or 8 bytes for each
reference).

So if you have a lot of references it could end-up over the limit.

Thanks,
Schneider
 
eschneider said:
Ok, but you point is they do count for something (4 or 8 bytes for each
reference).

So if you have a lot of references it could end-up over the limit.
I'm not sure the CLR actually supports a class with over 21,250 fields, but
if it does, yes, an instance of such a class would go in the LOH...

Usually only arrays end up in the LOH. Few instance objects are big enough
to take up >85K on their own.
 
Hello Schneider,

Jeroen has given a very good explanation about this issue.

In addition, a class can also exceed the size threshold if it contains lots
of large structures, since the structure members will also be allocated
inside the memory area of the object instance.

I'd like to provide the following article written by Maoni that is related
to this issue:
Large Object Heap Uncovered -
http://msdn.microsoft.com/en-us/magazine/cc534993.aspx

If you need additional information on this please let me know.

Have a nice day!

Sincerely,
Feng Chen([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
For MSDN subscribers whose posts are left unanswered, please check this
document: http://blogs.msdn.com/msdnts/pages/postingAlias.aspx

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications. If you are using Outlook Express/Windows Mail, please make sure
you clear the check box "Tools/Options/Read: Get 300 headers at a time" to
see your reply promptly.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.





--------------------
| Reply-To: "eschneider" <[email protected]>
| From: "eschneider" <[email protected]>
| Subject: Large Object Heap
| Date: Fri, 27 Jun 2008 14:05:29 -0500
| Lines: 24
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
| X-RFC2646: Format=Flowed; Original
| Message-ID: <[email protected]>
| Newsgroups: microsoft.public.dotnet.framework
| NNTP-Posting-Host: jules.starkinvestments.com 12.168.47.9
| Path: TK2MSFTNGHUB02.phx.gbl!TK2MSFTNGP01.phx.gbl!TK2MSFTNGP05.phx.gbl
| Xref: TK2MSFTNGHUB02.phx.gbl microsoft.public.dotnet.framework:14955
| X-Tomcat-NG: microsoft.public.dotnet.framework
|
| When determining the size of the object for the LOH, I assume that sub
| objects (like Address in the Person class) are excluded?
|
| class Person
|
| string NameLast
| string NameFirst
| Address AddressHome
| Address AddressWork
|
| end class
|
| class Address
| string Street
| string State
| string City
| string Zip
| end class
|
| Thanks,
|
| Schneider
|
|
|
 
Feng said:
In addition, a class can also exceed the size threshold if it contains lots
of large structures, since the structure members will also be allocated
inside the memory area of the object instance.

....which would only happen if the structures were badly designed in the
first place. A structure should not be larger than 16 bytes, or there
isn't really a point in making it a structure.
 
eschneider said:
When determining the size of the object for the LOH, I assume that sub
objects (like Address in the Person class) are excluded?

class Person

string NameLast
string NameFirst
Address AddressHome
Address AddressWork

end class

class Address
string Street
string State
string City
string Zip
end class

Thanks,

Schneider

Only the references themselves (plus a little book keeping overhead) are
included when calculating the size, so it is not very likely that a type
by itself will cause instances to be allocated in the LOH. Arrays and
strings are the most likely candidates for LOH.

There's an excellent treatment of how the LOH works in one of the latest
issues of MSDN magazine (I don't have the issue at hand, but I'm sure
you can find it through a search).

Regards,
Brian Rasmussen [MVP C#]
 
Back
Top