Jonathan S. Shapiro wrote:
On Sun, 2005-08-28 at 18:41 +0700, Constantine Plotnikov wrote:
I hope that that the section will answer the following questions:
- What are different memory classes supported? (so far single heap and
per thread stack as I understand, but there might be other memory
classes like constant pool)
There is a single heap. There is no language-supported concurrency, so
there is one stack and zero threads.
Possibly I'm missing something. C does not have lanuguage supported
concurrency, however it is possible to write multithreaded programs
using it. If BitC is a general purpose system programming language, it
might happen that some BitC programs will be written for platforms that
support/require multithreading.
Also as I understands Coyotos kernel is going to be written in BitC. How
you are going to support SMP without at least shared memory
interactions? BTW current predictions by Intel and AMD are that about 70
percent of new PC will have dual core processors by end of next year.
The language specification does not require, suggest, or imply the
creation of a constant pool. The compiler is free to unify identical
literal constants, but is not required to do so.
- When stack and heap memory are alloacted? (list of memory allocation
primitives possibly with just references to other sections of the
specification)
This is a tricky question. My view is that we *must* specify this for
the "manual storage" operating mode, but that we should not specify this
for the "managed storage" mode.
Where I can read about "manual" or "explicit" storage model?
[cut]
I should note that I have come to the conclusion that we need to think
through three modes of execution:
1. Explicit: the only runtime storage allocation arises from cases
(1, 2) above, which are explicitly under user control.
2. Non-collecting: case (3) is permitted, but only when the resulting
storage is not collectible. This would permit runtime procedure
instantiation and runtime dictionary construction.
3. Collecting -- cases (1,2,3) are permitted.
In Real-Time Java specification one application and even one thread can
change between modes of operation similar these ones and some
additional. Is process mode alterable in BitC?
The reason we need to consider the "non-collecting" case is to force us
to think through some issues; I don't intend to implement this.
Note that "explicit" mode is definitely going to require whole program
compilation.
Will dynamic linking with grounded definitions be allowed? If yes, will
be there additional restrictions of dynamic linking?
- When and how memory is deallocated? (spec seems to assume garbage
collector, but it is not spelled out explicitly)
In explicit mode: when you say so.
In collecting mode: when we feel like it, and the spec will not say (at
this time).
However: I've already built a simple mark/sweep allocator, and it
appears to be feasible to build several storage managers that can use
mostly the same code implementation. More precisely, there is an
optimization threshold below which this remains feasible.
Just a small off-topic question, are these storage managers written in
BitC or can be they written in BitC?
[cut]
Parts of this information is spreaded across the specification, other
seems to be assumed. I would like to see such information in one place.
Yes. Part of my hesitation to specify too early is that I want to know
that we can implement the requirements.
On other hand until it is formally specified, it cannot be discussed
with enough rigor. So it might be a good idea to have this information
in the specification with mark "under consideration". Other options is
to have these ideas expressed as document that are something like SFRI
for schema.
Also: you missed one issue that is really important: when are
stack-based pointers nullified?
It is very easy to have retained garbage resulting from stack frame
pointers that are no longer in scope but have not been explicitly
cleared. This is further complicated in BitC by the fact that NULL is
not always a legal pointer value (compare REF to OPTION), so there are
cases where the nullification MUST be inserted by the compiler. Matters
are still further complicated by the fact that the compiler may do
temporary consolidation, which makes deciding when to nullify
challenging for the user to get right.
In Java there is other complication. User might want to have resource
not to be garbage collected while reference is being held. In Java if
native resource is being wrapped by object, finalization often closes
resource handle. It might be an intention of the program to force
resource not to be closed while other activations are being processed.
Note that this was bad practice for number of reasons. However with some
badly designed third-party libraries that was a necessity.
I do not know if there will be the same complication in BitC because
foreign function interface and its interaction with storage model are
somewhat underspecified.
Constantine
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
