Re: P-Source: A Guide to the Apple Pascal System

On Nov 29, 10:45 pm, David Schmenk <dschm...@xxxxxxxxxxxxxx> wrote:

I am allocating stack space piecewise in predefined chunks from the
heap. Activation frames will be allocated from these chunks until it is
full, then allocate another chunk and link to it. Having multiple
threads and one stack wasn't a workable solution. Now they can be
allocated dynamically, managed like anything else in the heap, and even
swapped if they don't contain the current activation frame.

I will have a background thread that runs garbage collection and calls
finalize methods.

This sounds like a pretty full-featured JVM. I seriously doubt if you
can be faster than Apple Pascal with this model but I do like what
you're doing. I was alluding to the inappropriateness of this
comparison in an earlier message. It's not fair to directly compare 2
things that are quite different. It would be extremely exciting to
hear that you can even come close to the performance of Apple Pascal
with a real garbage collection and multi-threading OS, but I just
don't want you to be dismayed if that doesn't happen.

UCSD is pretty fast given what it's doing. Their primary goal seems to
have been tight code, however, so by careful design of the byte code
you might have a shot at beating them. Especially if you are willing
to slightly accept larger runtime code in order to avoid decoding so
many tightly packed fields.

But when you add garbage collection and threading you're taking a
performance hit that is probably greater than any savings you can get
by recoding the low-level p-code/bytecode. So the end result of your
work may be a little slower in a non-trivial real-world style user
program. But the features your adding may prove quite useful over the
long term. And the long-term definitely does matter here! Apple II's
have at least another 20 years of life left in them. I can't say that
about the Dell I'm working on now - It will be in the garbage heap
within another year.

Eric
.

Relevant Pages

  • Re: P-Source: A Guide to the Apple Pascal System
    ... then allocate another chunk and link to it. ... allocated dynamically, managed like anything else in the heap, and even ... I will have a background thread that runs garbage collection and calls ... Threading should have close to zero impact on performance. ...
    (comp.sys.apple2)
  • Re: Garbage collector and multiple threads
    ... > The only way to prevent Garbage Collection is to create no garbage. ... > additional heap objects, then no Garbage Collections will occur. ... Do AppDomains have separate heaps, ... > The only other thing I can think of is that if you allocate little enough ...
    (microsoft.public.dotnet.framework)
  • Re: P-Source: A Guide to the Apple Pascal System
    ... then allocate another chunk and link to it. ... allocated dynamically, managed like anything else in the heap, and even ... I will have a background thread that runs garbage collection and calls ... Threading should have close to zero impact on performance. ...
    (comp.sys.apple2)
  • Re: Huge pages and small pages. . .
    ... >> what looks like contiguous memory and away you go. ... you need to have them cached in the TLB; if the TLB runs out of ... > low end of the heap, until someone figures out a way to tell the system ... When you allocate memory, the kernel just marks a promised ...
    (Linux-Kernel)
  • Re: Struct inside class
    ... The compiler figures computes the ... including anything derived from "Object": Heap pointer ... memory leaks and why the .NET good garbage collector is required. ... If GC_ALLOCATE can't allocate the requested ...
    (microsoft.public.dotnet.framework)