Hi JZr,
please see my comments inline.
Jiří Zárevúcky wrote:
"
Hi everyone.
So, right now I am trying to figure out how best to integrate Go support to
HelenOS mainline. Some of you know that the way I support Go in my personal
branches is not quite satisfactory to me.
"
Getting Go into HelenOS mainline is a nice thing. I don't see any reason not
to do it. Especially if there are some interesting applications written in
Go which could be brought to HelenOS this way. As long as someone (e.g. you)
is willing to maintain it, sure thing.
"
First of all, let me explicitly state the "why". My intention behind Go
support is to have a modern, reasonably memory-safe language to write system
components with.
"
Regarding that - I have no problems if you want to use it for
experimentation / writing prototypes. Writing HelenOS components in Go is a
different thing altogether. The status quo is that HelenOS is written in C
and IMHO allowing a new language for implementation of the system would
require a broader discussion and concensus.
"
That means several things. First, it is unnecessary to support all the
features from the start (as long as it is easy to just not use them).
"
Agreed, that's kind of obvious.
"
Second, there should be as little mandatory library code as possible
(trusted computing base). Third, since Go is garbage-collected (in itself a
good thing, since it helps memory safety, but may be bad for performance
and/or memory use), we may want to make it possible to optimize programs wrt
memory usage and fine-tune the allocator's and garbage-collector's behavior.
Note that all contemporary Go compilers (most importantly gccgo) emit native
machine code, so there is no virtual machine. Also, code compiled by gccgo
can directly call C-language functions.
"
OK
"
With all that in mind, here is what I have come up with so far:
lib/gocore:
The basic runtime support (mostly support for important function calls
emitted by the gccgo compiler). As little code as possible if it can be
helped. Non-critical parts of the runtime should be kept in a separate
library if possible.
(maybe) lib/gomore:
In case some functionality can be stripped down to basics for the default
variant, this library can contain a more complex full-featured
implementation. One example that comes to mind is profiling/debugging
features and such things.
lib/gomem:
Memory allocator and garbage collector (mostly copied from the official
distribution). This is an important component, but keeping it in a separate
library makes it possible to write different implementation of the same
thing if useful. Not to mention it's a huge piece of code and modularity is
always good.
lib/gomap:
Hash map implementation. Hash map is a native type in Go, but it is not
critical for anything and still a very complicated piece of code.
""
lib/gochan:
Channel implementation. Same reason as above.
"
Firstly, how Go support will exactly be implemented is probable the least
important question to me from the set of questions posed. I will try to
think about it carefully, nevertheless.
Let me try to decompose your proposal into atoms.
You propose:
1) to implement Go runtime support in a set of libraries (as opposed to one
library)
2) specifically you propose what those libraries are and how the
functionality would be split
I am not familiar with Go to be able to comment on #2. As far as #1 is
concerned, I have nothing against the split, I would maybe advise to put all
the libs in one subdir, e.g. lib/go/(go)core, lib/go/(go)more, etc. It is
not clear to me, however, what specific benefit you expect from having the
runtime in multiple parts instead of one? Will that affect the way the
binaries will be linked? If so, how? Will I always link with all the
libraries or just a subset? If I'll link with all of them, isn't that an
unnecessary complication? If I link with just some of them, how will I
figure out which libraries I need to link with?
"
golib directory - since Go code has modular structure through "packages",
and generally does not use makefiles, a separate golib directory would be
useful for them. This directory would contain all the Go libraries written
specifically for HelenOS. Also, a support for automatically downloading and
building third-party packages (e.g. parts of the official package library
[1], and other useful stuff[2]) would be nice.
"
Naturally.
"
Noncritical parts of the runtime that can be implemented in Go would also go
here.
"
Sounds reasonable.
Cheers,
Jiri
"
-- Jirka Z.
[1] http://golang.org/pkg/(http://golang.org/pkg/)
[2] http://golang.org/doc/code.html#remote
(http://golang.org/doc/code.html#remote)
"
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
