Asp Forum - Large Object Heap - microsoft.public.dotnet.framework

eschneider

6/27/2008 7:05:00 PM

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

7 Answers

Jeroen Mostert

6/27/2008 7:31:00 PM

eschneider wrote:
> 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...

--
J.

eschneider

6/27/2008 7:50:00 PM

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

"Jeroen Mostert" <jmostert@xs4all.nl> wrote in message
news:48654009$0$14359$e4fe514c@news.xs4all.nl...
> eschneider wrote:
>> 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...
>
> --
> J.

Jeroen Mostert

6/27/2008 7:54:00 PM

eschneider wrote:
> 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.

--
J.

v-fengch

6/30/2008 9:48:00 AM

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/cc5...

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

Have a nice day!

Sincerely,
Feng Chen(v-fengch@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

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

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default....
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/de....
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
| Reply-To: "eschneider" <eschneider@community.nospam>
| From: "eschneider" <eschneider@community.nospam>
| 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: <OOSOFjI2IHA.2068@TK2MSFTNGP05.phx.gbl>
| 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
|
|
|

Göran Andersson

7/1/2008 10:41:00 AM

Feng Chen[MSFT] wrote:
> 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.

--
Göran Andersson
_____
http://www...

eschneider

7/1/2008 7:35:00 PM

Yes, given the logic, it's seems difficult to exceed the limit.

"Göran Andersson" <guffa@guffa.com> wrote in message
news:%23Ifsxb22IHA.2348@TK2MSFTNGP06.phx.gbl...
> Feng Chen[MSFT] wrote:
>> 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.
>
> --
> Göran Andersson
> _____
> http://www...

Brian Rasmussen [C# MVP]

7/7/2008 9:34:00 PM

eschneider wrote:
> 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#]

microsoft.public.dotnet.framework

Large Object Heap

eschneider

Jeroen Mostert

eschneider

Jeroen Mostert

v-fengch

Göran Andersson

eschneider

Brian Rasmussen [C# MVP]

x Login to ForumsZone