closing and re-opening CPUs in opcodes

closing and re-opening CPUs in opcodes

[Graydon Hoare]

hm. stress-induced brain seisure, please ignore previous message.
the function in question of course doesn't *receive* a handle,
and must go find one by other means, so naturally it caches it in
a static. 

not that this fixes much, but it does explain it. I'll work out a
fix on my own though. never mind.

-graydon

closing and re-opening CPUs in opcodes

[Graydon Hoare]

Hi,

When doing multi-CPU simulation in sid, on cgen-generated CPU
cores, with --trace-disassemble, opcodes is called once per insn
to do the disassembly. If two calls come with different CPU
description handles, opcodes will *notice* this fact, via a
static handle it keeps in function scope telling it how it was
last called, and close/re-open the handle it's being called with.

This has a couple penalties associated with it. First, it reveals
a number of hidden memory leaks between CPU description open and
close (and I've not found all of them yet). Second, it is
actually quite expensive in terms of simulator cycles, since we
re-initialize a bunch of tables, rebuild assembly regexes, etc.
every time we re-open a CPU description. 

When you run with large-ish blocks between CPU yields, this is
not too bad. When you run the CPUs in lock-step, to give a good
"simulated concurrency", it is intolerably slow (and quickly eats
all available memory). Is there any particular reason why, in
opcodes' "handle oriented" interface, we're closing and
re-opening? Shouldn't the handles isolate all the resources
they're responsible for? 

I'll keep digging, but any additional insight would be
appreciated.

-graydon