misc thing (my lang): vm handling of external objects
- From: "cr88192" <cr88192@xxxxxxxxxxxxxxxxxx>
- Date: Tue, 8 Aug 2006 18:06:50 +1000
oh well, not much traffic recently anyways.
just figured someone might have something interesting to say...
so, recently (in the process of integrating my newer vm back into my main
codebase), I have had to deal with a problem:
objects need to be shared, but the memory management systems are completely
different.
as such:
it isn't possible to pass around external references inside the vm;
it isn't really possible to (safely) pass vm references around outside the
vm (it is rather anal, with ref-counting, precise collection,
marking/coloring, and roots registration, among other things...).
likewise, the codebases are kept seperate, so:
the vm knows nothing of the outside world;
only the direct interface code will know anything about the vm.
and at the same times, the internalized objects need to behave more or less
like native objects. this means at least part of the interface needs to
exist within the vm.
dunno what other people have done in this case, but the vm's I had looked at
once before (scm and guile) didn't seem to address this.
so, what I did was more or less this:
I have implemented a type, which basically just says "yeah, external
object", and is otherwise completely opaque.
it is implemented as a tagged reference holding a handle for the object. it
is checked for in a number of places, and if detected passes control to the
external interface (handle) code.
this code uses a set of arrays, which basically assume that the external
objects are untyped void pointers. a set of function pointers is kept which
are assumed to know how to work with these types (the external system is
based around dynamically typed void pointers, which at least makes this a
little more convinient).
note that there are multiple "spaces" here, each one with a different set of
arrays and methods (241 in total, where the first is special and 16x as
large as the others, of which there are 240, each with a max of 64k external
references).
note that there is nothing stopping me (in theory) from also using this
system to refer to network based objects (thus, an important part of a dsm
setup may have already been implemented here).
the other side of the interface (probably will be implemented somewhere or
another in the external codebase) will manage the export of vm references
(likely via a similar means), and will know at least something about the vm
(that or the export system could be partly implemented within the vm, as at
least it has a good idea how to manage exported objects).
so, likely, the export will be via integer handles, and will be similarly
opaque, and these integers would be boxed. boxing is ok here, as I can
assume that external data will much more often be handled within the vm than
vm data within the external codebase.
these boxes will be types, and will similarly direct control back into the
vm when accessed. otherwise, type marshalling will be handled in the
external part of the interface (it will have to understand both systems, and
readily convert between them), and so on...
everywhere else, the code will not be expected to know the vm exists at all,
and it will treat the objects more or less as usual.
note that my previous vm's were implemented in terms of the external
codebase/typesystem, but the vm was split off and now uses its own system
for the reason that the old typesystem was inefficient (a basic part of its
operation being the generation of abundant amounts of garbage, and a
necissarily slow gc).
for (partly) these reasons, a newer vm was implemented using a
self-contained system...
or such...
.
- Prev by Date: Aurora Alpha 3 Rev 8
- Next by Date: test Cisco question
- Previous by thread: Aurora Alpha 3 Rev 8
- Next by thread: test Cisco question
- Index(es):
Relevant Pages
|
