/CLR bloats image with unreferenced code in VC8

[Bern McCarty]

We upgraded a bunch of MEC++ code to C++/CLI about 11 months ago and we've
noticed that our images bloated quite a lot in the process. Upon
investigating I observed that when a /clr compiland includes a header file
for a native type that has an inlined copy constructor, that both the
inlined copy constructor and the inlined destructor for that same type will
end up in my mixed image, even though there is no reference made to that
native type from the source code of my dll at all. This is true even if the
..h containing the native type is included in a #pragma unmanaged section of
my compiland.

This seems like a bad compiler bug to me. I should pay zero runtime penalty
for including type information for types that I do not reference at all.
Don't you agree? Otherwise I have to go to the almost impossible difficulty
of minimizing the native type information observed by my mixed compiland.
But that ain't the C++ I know. That is an intractable task.

This bug is particularly annoying when it forces you to link with an import
library for a dll that you shouldn't have to link with at all. Suddenly your
binding closure balloons for no justifiable reason. This happens when you
see a native type (that you do not use) with an inline copy constructor and
destructor that references something in some other .dll (that you also do
not use). This bug may have something to do with exception handling/stack
unwinding. The linker errors that can be observed when unexpected stuff is
dragged into your .dll image often mention some "_unwindfunclet " symbol that
I know nothing about. This dragging in of unused code into images is
increasingly responsible for breaking our builds.

I implore someone from the Visual C team to investigate this. Reproducing it
is trivial. Start with a native hello world C++ program that arbitrarily
includes some not-really-referenced-or needed headers for some native types
that have inlined copy constructors and destructors that call out to other
..dlls whose import libraries you do not link with. Put #pragma unmanaged at
the very top of the program and first make sure that it compiles just fine
as a pure native image and that it runs. Now, slap /CLR on the compile and
try again. Now you will get link errors and you will see that it tracks
back to the unused native types that have inlined copy constructors.

Can someone from Microsoft please comment on this problem?

Bern McCarty
Bentley Systems, Inc.

[Ben Voigt [C++ MVP]]

"Bern McCarty" <be*****@newsgr oup.nospamwrote in message
news:60******** *************** ***********@mic rosoft.com...

We upgraded a bunch of MEC++ code to C++/CLI about 11 months ago and we've
noticed that our images bloated quite a lot in the process. Upon
investigating I observed that when a /clr compiland includes a header file
for a native type that has an inlined copy constructor, that both the
inlined copy constructor and the inlined destructor for that same type
will end up in my mixed image, even though there is no reference made to
that native type from the source code of my dll at all. This is true even
if the .h containing the native type is included in a #pragma unmanaged
section of my compiland.

This seems like a bad compiler bug to me. I should pay zero runtime
penalty for including type information for types that I do not reference
at all. Don't you agree? Otherwise I have to go to the almost impossible
difficulty of minimizing the native type information observed by my mixed
compiland. But that ain't the C++ I know. That is an intractable task.

This bug is particularly annoying when it forces you to link with an
import library for a dll that you shouldn't have to link with at all.
Suddenly your binding closure balloons for no justifiable reason. This
happens when you see a native type (that you do not use) with an inline
copy constructor and destructor that references something in some other
.dll (that you also do not use). This bug may have something to do with
exception handling/stack unwinding. The linker errors that can be
observed when unexpected stuff is dragged into your .dll image often
mention some "_unwindfunclet " symbol that I know nothing about. This
dragging in of unused code into images is increasingly responsible for
breaking our builds.

I implore someone from the Visual C team to investigate this. Reproducing
it is trivial. Start with a native hello world C++ program that
arbitrarily includes some not-really-referenced-or needed headers for some
native types that have inlined copy constructors and destructors that call
out to other .dlls whose import libraries you do not link with. Put
#pragma unmanaged at the very top of the program and first make sure that
it compiles just fine as a pure native image and that it runs. Now, slap
/CLR on the compile and try again. Now you will get link errors and you
will see that it tracks back to the unused native types that have inlined
copy constructors.

Can someone from Microsoft please comment on this problem?

Others have mentioned this behavior before, that unused native types end up
in the final image. I suspect that is an inadvertant result of a design
choice to not remove unused managed types (they could still be used through
reflection, after all), possibly combined with the metadata generated even
for native types.

I suggest that you file a bug on Microsoft Connect, and include real code
for your "trivial" reproduction.

>
Bern McCarty
Bentley Systems, Inc.

[Jeffrey Tan[MSFT]]

Hi Bern,

Do you mean something like this? We can't seem to get it to repro with my
simple repro.

D:\repro\unref_ code_managed>ty pe myheader.h
#include <stdio.h>

#pragma managed(push, off)
__declspec(dlli mport) void SomethingFromDl l();

class Foo
{
public:
Foo()
{
printf("Foo ctor()");
}
Foo(const Foo& rhs)
{
printf("Foo copy-ctor()");
}
void doSomething()
{
SomethingFromDl l();
}
~Foo()
{
SomethingFromDl l();
printf("Foo dtor()");
}
};

#pragma managed(pop)

D:\repro\unref_ code_managed>ty pe t.cpp
#include <stdio.h>
#include "myheader.h "

void main()
{
printf("Hello world!");
}

D:\repro\unref_ code_managed>cl t.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for
80x86

Copyright (C) Microsoft Corporation. All rights reserved.

t.cpp
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.

/out:t.exe
t.obj

D:\repro\unref_ code_managed>t
Hello world!
D:\repro\unref_ code_managed>cl /clr t.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.762
for Microsoft (R) .NET Framework version 2.00.50727.1302
Copyright (C) Microsoft Corporation. All rights reserved.

t.cpp
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.

/out:t.exe
t.obj

D:\repro\unref_ code_managed>t
Hello world!
D:\repro\unref_ code_managed>

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

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/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.

[Jeffrey Tan[MSFT]]

Hi Bern,

Have you reviewed my reply to you? Can you provide more details to help me
reproduce this problem? Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

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/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.

[Bern McCarty]

Hi Jeff,

Yeah that's the idea. I tried your example with the same result (no repro)
so then I preproc'd one of our real header files and modified your example
to use it and then I was able to get an unresolved external link error (but
only with /CLR added). The preproc'd header is pretty big. Can you give me a
place to upload the repro?

-Bern
""Jeffrey Tan[MSFT]"" <je***@online.m icrosoft.comwro te in message
news:WC******** ******@TK2MSFTN GHUB02.phx.gbl. ..

Hi Bern,

Have you reviewed my reply to you? Can you provide more details to help me
reproduce this problem? Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

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/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no
rights.

[Jeffrey Tan[MSFT]]

Hi Bern,

Thanks for your feedback.

MSDN newsgroup support policy normally does not cover very large production
code. Microsoft CSS phone support is more suitable for large file
troubleshooting .

Anyway, if you want I will try my best to help you. You may attach the file
as an attachment through Outlook Express or you may email it to me at:
je***@online.mi crosoft.com(remove "online."). Please also provide the
detailed steps to use this file and for reproducing. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

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/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.