2. Heaps: Regardless of paging, we have to have a heap before we can
support managed runtime code.
1. ...and Paging
1. Do we want to have a unique heap on each page? Or just
a unique heap per appdomain? (I would think per-page...)
2. Wouldn't the set of pages behave, on an abstract level,
like a heap of data?
1. If so, couldn't we re-use some code? (Which would
make the code easier to maintain, wouldn't it? And easier
to optimize?) The
functions would just use pointers anyway. But I don't know
how the MMU would
fit in...
2. But if we share pages, then deallocation/GCing
pages (think: reference counts, synclocks, etc), will
work, in essence,
similar to deallocation/GCing of stuff on a normal heap?
2. ...and GCing
1. A seperate GC per heap? (Or is this a threading issue?)
I would like to assume that GC data can somehow be stored with the
object-overhead there with the object on the heap. (e.g.
what generation is the current object in? Is it on the "large
object heap"
or not?) I would assume not putting the data with each
object, because then
it would free up issues with different possible GCing algorithms.
3. ...and Threading
1. We have to make sure we synclock our heaps, don't we?
So that if the heap is being changed by one thread, that it
doesn't become
changed by another.
4. ...and AOTing EDC korlib code to support the VM/JIT
1. We need to have our stubs marked with attributes to
control what kind of code the AOT injects to make allocate
managed objects.
2. The memory management stubs for AOTed EDC code, will
perhaps, be different in signature from the kinds of stubs
that the VM/JIT
will use.
1. If you are AOTing something, how does the AOT
know which page, heap, etc., (for the allocation
stub-calls that it is
injecting), that you want to allocate the objects on?
2. Granted, the AOT *can't really know* - so do we
want to have overrides that are internal to the kernel
that default to
kernel space? How do we want this to work?
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
