[Mono-bugs] [Bug 38532][Wis] New - Supporting the #- heap.

[bugzilla-daemon@rocky.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by miguel@ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=38532

--- shadow/38532	Sat Feb 22 14:34:35 2003
+++ shadow/38532.tmp.1589	Sat Feb 22 14:34:35 2003
@@ -0,0 +1,71 @@
+Bug#: 38532
+Product: Mono/Runtime
+Version: unspecified
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Wishlist
+Component: misc
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: miguel@ximian.com               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Supporting the #- heap.
+
+This bug only contains information about the #- heap.  The idea is to track
+here the information we have about it, and what can be done to implement it.
+
+This is from a post to mono-list from Paolo Molaro:
+
+
+> > I'll add a message that will get printed when the #- heap is found:
+> > you need to compile the assemblies without the /incremental switch
+> > (use the Release mode instead of the Debug one). The #- heap is an
+> > internal MS format that is not standardized. Some info was posted to
+> > this list a while ago: it should not be hard to support it in mono, but
+> > I don't have the time to implement it right now. Any volunteers?
+> 
+> I do not remember reading anything that would contain useful information
+> about the #- heap.  Could you post your thoughts on this?
+
+Serge posted some useful info a while back, including the name of the
+additional tables (FieldPtr, MethodPtr, etc). I think his PE-reading
+code also has the table index values.
+He also posted the instructions to get csc to produce binaries with that
+heap, so that we can produce them at will and check the format: given
+two files to compile, these commands will generate it:
+        csc -out:bin.exe -debug+ -optimize- -incremental+ a.cs b.cs
+        touch a.cs
+        csc -out:bin.exe -debug+ -optimize- -incremental+ a.cs b.cs
+                        
+Then, since they call it uncompressed, I assume the column values have a
+fixed size of 4 bytes integers instead of following the normal rules
+for compression (implemented in mono in mono_metadata_compute_size ()).
+Also, a few days ago I had an idea about how they could use the FieldPtr
+and related tables. In the normal #~ heap for each type you have the
+FieldList column that points at the first field for the type, all the
+other fields are layed out sequentially after that, until the end of the
+table or until the first field of another type. With incremental
+compilation this is not possible, since the fields may be created out of
+order. So I guess they use the FieldPtr table as a linked list.
+
+The FieldPtr table has two columns both of which are indexes in the Field
+Table. The FieldList column in the TypeDef table points to the first
+field for the type as usual, but to find the next field, you have to
+lookup the row in FieldPtr with the same field index in the first column
+and you'll use the field index in the second column to find the next
+field for the type.
+The same process can be applied to MethodPtr, EventPtr and the like.
+Mind you, I haven't checked yet with a real #- heap if the above ideas
+are correct, but maybe this info can be helpful for some enterprising
+contributor:-)
+
+Of course, the MS people listening should feel free to correct any
+mistakes in the description or better yet provide us the documentation
+for the format:-)
+
+lupus