-
Notifications
You must be signed in to change notification settings - Fork 223
Remove custom heap #486
base: dev
Are you sure you want to change the base?
Remove custom heap #486
Changes from all commits
82e276d
8179460
b977a84
ecd0fa3
6a8107e
27f1ea7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -9,8 +9,6 @@ | |
|
||
#include "tinyhal.h" | ||
|
||
HAL_DECLARE_NULL_HEAP(); | ||
|
||
void ApplicationEntryPoint() | ||
{ | ||
int nSects = 0; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -109,8 +109,8 @@ HRESULT CLR_GFX_Bitmap::CreateInstance( CLR_RT_HeapBlock& ref, const CLR_GFX_Bit | |
} | ||
else | ||
{ | ||
//The bitmap is too big to fit on the managed heap, so put it on the SimpleHeap | ||
bitmap = (CLR_GFX_Bitmap*)SimpleHeap_Allocate(size); | ||
//The bitmap is too big to fit on the managed heap, so put it on the heap | ||
bitmap = (CLR_GFX_Bitmap*)malloc(size); | ||
|
||
ref.SetInteger((CLR_UINT32)bitmap); | ||
ref.PerformBoxingIfNeeded(); | ||
|
@@ -195,7 +195,7 @@ HRESULT CLR_GFX_Bitmap::CreateInstance( CLR_RT_HeapBlock& ref, const CLR_UINT8* | |
/* When loading a Windows BMP, GIF, or JPEG file, it is converted in-place to the native BPP. | ||
* When loading a compressed TinyCLR Bitmap from a resource file, two bitmaps are needed to decompress, then convert. | ||
* This fragments the heap and wastes space until the next garbage collection is done. | ||
* When using the SimpleHeap, there is no relocation, so decompressing into a temp bitmap into the simpleheap wastes | ||
* When using the heap, there is no relocation, so decompressing into a temp bitmap into the heap wastes | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The comment shouldn't just blindly replace words with a GREP, it needs to be re-worded to reflect the consequences. The platform creator should still have the option of creating a simple heap/big object storage to support large bitmaps that are otherwise not supported in the managed heap. (One of the implementation details in the managed heap is an assumption on the maximum size of any single allocation) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not following you here... A platform creator can make the standard heap as large as he wants to hold these graph and whatever stuff it's needed. I don't see why this comment is misleading or not providing enough explanations for an informed decision. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The large object heap was isolated for a reason, to allow the OEM to partition out memory used for LARGE objects. Throwing everything into one big heap may be a simple solution to port but can lead to fragmentation problems, which is why the large buffer and bitmap images were isolated into a separate heap. This might be something an OEM could manage using a custom implementation of malloc()/free() (e.g. use the size parameter of malloc to determine which underlying region to allocate from), but doing so is more difficult as replacing the standard functions is slightly less than intuitively obvious to the casual observer 😉 and compiler/tool specific. While I'm all for getting rid of custom heap use for the normal PAL/HAL work (that should stick with standard malloc for greater portability and re-use) I think it makes life easier for ports needing large buffers to still have this as an option. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My suggestion was to remove the custom heap. Which I did, for GCC. And I suspect it should be easy for someone knowledgeable to port this to MDK. Wasn't aware of this nuance of "large objects". Feel free to take what's done and incorporate any changes required to making the options you mention available. |
||
* memory 6.25% the size of the 16bpp bitmap that's saved. | ||
*/ | ||
|
||
|
@@ -310,7 +310,7 @@ HRESULT CLR_GFX_Bitmap::DeleteInstance( CLR_RT_HeapBlock& ref ) | |
if (blob->IsBoxed() && blob[ 1 ].DataType() == DATATYPE_U4) | ||
{ | ||
bitmap = (CLR_GFX_Bitmap*)(blob[ 1 ].NumericByRefConst().u4); | ||
SimpleHeap_Release (bitmap); | ||
free(bitmap); | ||
} | ||
else | ||
{ | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Umm, hold on a sec... This is defining the managed heap APIs. The HAL_DECLARE_CUSTOM_HEAP creates a set of private_xxx APis that are inlined wrappers around the methods listed in the macro. While the entire approach to using a macro like this is dubious at best, we don't want to eliminate the functionality as intended here. The use here is intended to be the managed heap which has lots of internal requirements and assumptions for the collector to work properly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you entirely sure about that?!
The name refers to custom heap.
I have build this without this code and it went fine.
I have loaded the image on real hardware a run a test app. Creating and destroying objects. Checked the managed memory going up and down a seeing the GC kicking on. I admit it wasn't nothing fancy or exhaustive but it proved that the managed heap was working.