Turn on Loh compression?

We know that there is a special heap in the GC heap of the. NET CLR that specializes in storing objects over 85000byte (see here), which is the large object heap (LOH).

Prior to the. NET Framework 4.5.1, Microsoft did not provide compression operations on the Loh because the overhead of moving large objects was considerable. The inability to compress the Loh also poses some problems, such as the Loh's memory fragmentation. However, in the. NET Framework 4.5.1, Microsoft has added a switch to the Loh heap compression. For why this switch is added, personal speculation should be that computer performance is sufficient to support this operation. Refer to the following code for specific use:

Gcsettings.largeobjectheapcompactionmode = gclargeobjectheapcompactionmode.compactonce; Gc. Collect ();    

The explanation for Gclargeobjectheapcompactionmode.compactonce is that the LOH is compressed the next time the Gen2 is recycled. In other words, this setting is only one effect per execution, and this design is reasonable, after all, if it is a permanent switch, it will cause unnecessary compression operations. Although computer performance is sufficient to support the compression operation of the Loh, this does not mean that performance is not affected.

So, how do I know that this operation has achieved the desired effect? This will be on the debug artifact WinDbg, although similar to Clrprofiler can be seen, but on the amount of information WinDbg to win a raise.

First, test the code:

Class program{    static void Main (string[] args)    {        //Put a large object on the Loh heap and the object is considered garbage        Makealohobject () after the call;        Put another large object on the Loh heap, at which point the object will be kept        var bytes = new byte[1024*1024];        Comment and uncomment the following switches, and dump the memory separately for analysis        Gcsettings.largeobjectheapcompactionmode = gclargeobjectheapcompactionmode.compactonce;        Triggers the all GC        GC. Collect ();        Console.read ();    }    static void Makealohobject ()    {        var obj = new byte[1024 * 1024x768];}    }

Here is an excerpt of the dump information for the uncompressed LOH switch:

0:000>!EEHEAP---------------Omitted partial information number of GC Heaps:1generation 0 starts at 0x000001450b255b90generation 1 starts at             0x000001450b251018generation 2 starts at 0x000001450b251000ephemeral segment allocation Context:none segment  Begin allocated size000001450b250000 000001450b251000 000001450b255ba8 0x4ba8 (19368) Large Object heap starts at 0x000001451b251000 segment begin allocated Size000001451b2 50000 000001451b251000 000001451b4599f0 0x2089f0 (2132464) Total size:size:0x20d598 (2151832) bytes.------              ------------------------GC Heap size:size:0x20d598 (2151832) bytes.0:000>!dumpheap-statstatistics: MT Count totalsize Class Name----------------omit some information 00007ff8edfa2160 2 706 system.char[]00007 FF8EDFA61A8 2 1072 System.Globalization.CultureData00007ff8edfa2360 1112 system.string[]00 007FF8EDFA2F10 26        1456 system.runtimetype00007ff8edfa1010 154 6696 system.string00007ff8edfa1688 5 35144 system.object[]00007ff8edfa7248 3 1048904 system.byte[]00000145095abf40 1051068 freetotal 2 94 Objects0:000>! DUMPHEAP/D-mt 00000145095abf40 Address mt size000001450b251000 00000145095abf40 Free0 00001450b251018 00000145095abf40 free000001450b251030 00000145095abf40 free----------------omit some information 0000014 51b259980 00000145095abf40 1048662 Free

From the!EEHEAP command results you can see that the Loh is 2132464byte, about 2MB, which means that although a 1MB byte array is reclaimed, the memory is not compressed. The freed 1MB space can be found from free in the!dumpheap-stat.

Next look at the memory dump that opens the compressed LOH switch:

0:000>!EEHEAP----------------Omitted partial information number of GC Heaps:1generation 0 starts at 0x0000015300005390generation 1 starts a             T 0x0000015300001018generation 2 starts at 0x0000015300001000ephemeral segment allocation Context:none segment Begin allocated size0000015300000000 0000015300001000 00000153000053a8 0x43a8 (17320) larg E object heap starts at 0x0000015310001000 segment begin allocated size0000015310 000000 0000015310001000 00000153101099b8 0x1089b8 (1083832) Total size:size:0x10cd60 (1101152) bytes.-----              -------------------------GC Heap size:size:0x10cd60 (1101152) bytes.0:000>!dumpheap-statstatistics: MT Count totalsize Class Name----------------omit some information 000001536ca7be30 414 FREE00007FF8 edfa8520 1 432 System.Collections.Generic.Dictionary ' 2+entry[[system.type, Mscorlib],[system.security.poli Cy. EvidencetypedescriptoR, Mscorlib]][]00007ff8edfa39d8 6 524 system.int32[]00007ff8edfa2160 2 706 system.char[]00 007FF8EDFA61A8 2 1072 System.Globalization.CultureData00007ff8edfa2360 1112 system.string[ ]00007FF8EDFA2F10 1456 system.runtimetype00007ff8edfa1010 154 6696 System.string00007ff8edfa 1688 5 35144 system.object[]00007ff8edfa7248 3 1048904 system.byte[]total 286 objects

It can be seen from above that the size of the Loh is not 1083832, that is, about 1MB, which means that the Loh is indeed compressed, and the!dumpheap-stat in the free space can not find this area. This is not really the point, the point is that since we use the Loh compression, then the LOH compression on performance will have much impact? First we understand that enabling Loh compression is not a direct impact on the execution performance of the code we write, but on the performance of GC reclamation. The prelude to GC recycling is to suspend all worker threads, so the time each execution of the GC determines how long the entire system will hang. Then post a piece of code that is used to count the average time spent on enabling and closing Loh compression: 

Class program{static void Main (string[] args) {var cycle = 1000;        var total = 0l;        Preheat makegrabage ();        for (int j = 0; J < cycle; J + +) {Total + = Makegrabage ();        } Console.WriteLine ("Average time {0} milliseconds", Total/(double) cycle);    Console.read ();        } Static Long Makegrabage () {var objs = new byte[1000][];        Initializes a byte array of 1000 1MB for (int i = 0; i < i++) {Objs[i] = new byte[1024 * 1024]; }//Place half of them as garbage objects for (int i = 0; i < Objs. Length;            i++) {if (i% 2 = = 0) {Objs[i] = null;        }} var sw = Stopwatch.startnew ();        Turn on or off loh compression gcsettings.largeobjectheapcompactionmode = gclargeobjectheapcompactionmode.compactonce; Gc.        Collect (); Sw.        Stop (); var elasped = sw.        Elapsedmilliseconds;        OBJS = null; Gc.        Collect ();    return elasped; }} 

In the above conditions, my machine ran out of the result is: Do not open the Loh compression average recovery takes 0.705 milliseconds, and the average recovery after the turn on 325.369 milliseconds, 461 times times worse. Memory consumption does not open the Loh compression average around 1400MB, open after the average around 850MB, memory is pure eyes, so may be larger than the gap. In terms of the above data, Loh compression is still used when it is necessary.

original articles, reproduced please specify: reproduced from the Xdlysk blog

This article link address: Open loh compression? [Http://www.xdlysk.com/article/5826c1d2b16bc40409d5cac8]

Turn on Loh compression?