[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon May 6 13:06:13 2003 
Subject:Re: Vector arguments to external procedures 
From:davidy 
Volume-ID:1030506.01 

Dear Steve and Aaron,

Thanks for your suggestions.

Unfortunately I think both the things Aaron mentions have drawbacks for
what I'm trying to do. First, sys_lock_heap. It's correct that sys_lock
heap can be used to solve my problem, since the locked part of the heap
is left alone by the GC. My worries are

    (a) locking and unlocking the heap involves non-trivial amounts of
    work, so the overhead might be considerable;

    (b) sys_unlock_heap unlocks the *whole* heap, which is no good as it
    might have been previously locked for a good reason, e.g. after
    compiling a large library. It looks as if decrementing
    pop_heap_lock_count should do the right thing, but I am wary of
    using something that isn't documented - maybe this variable wasn't
    documented because it can cause problems if used in this way.
    (sys_unlock_heap just sets pop_heap_lock_count to 0 by the way.)

Second, fixed address structures. Again, these provide one kind of
solution. Again I have two objections:

    (a) The arrays have to be specially created. I don't want to have to
    modify all my existing programs to make fixed address arrays! The
    idea is that the interface to Lapack (or whatever) should be a handy
    thing to have available, not something that determines how any other
    part of the program has to be written. (Of course I could create
    fixed address arrays locally and copy data into them - but copying
    data is what I'm trying to avoid in the first place.)

    (b) The data I'm handling often comes in large chunks (e.g. it's
    images), with a short lifetime, and of unpredictable size. I suspect
    that making much of it fixed address will fragment the heap
    disastrously.

I think, however, that I might be able to base something on Steve's
recent message:

> How about adding a pop_after_gc "hook" that is responsible for
> correcting the addresses that get mucked up?  The simplest way to do
> this is to modify Aaron's suggestion by "marking" the resulting exptr
> struct by adding it to a temporary property along with enough
> information to re-do the computation.  Then the pop_after_gc hack
> would re-run the computation.

One concern is whether I can grab the exptr structs quickly enough. The
code for sysFIELD ($usepop/pop/src/fields.p line 823) looks suspiciously
as if it gets the address before it makes the structure

            PUSH_FIELD_ADDR();
            exptr_result(not(addr_mode))   ;;; makes the struct I think

- so it could trigger a GC and invalidate its own result! Seems unlikely
that the author wouldn't have thought of this - is anyone expert enough
to comment? I guess I can cover this possibility (and that of triggering
a GC when the exptr goes on the stack) by using pop_after_gc to check
whether a GC occurred during address acquisition, and do it again if
necessary. 

A similar possibility that I'm also thinking about is always to get the
addresses just before the external call, storing vec and n in a local
structure, and to loop if a GC occurs during this phase. I *think* that
the code sysFIELD plants for the external call itself can't cause a GC
(the argument processing code is in assembler) - if that's correct, this
can be made to work.

Anyway, that was all for info to anyone still interested. I'll have a go
at something and let you know when I've got code I believe to be
correct.

Thanks for help so far.

David