Smalltalk › Instantiations

memory address of a ByteArray

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

wobotzen

memory address of a ByteArray

Hallo

when calling a cdll like

bytes: aByteArray

<c: uint32 'dllname':dllFunction pointer>

VA passes the pointer of the ByteArray to the dll, is it possible to get the value of 'pointer' inside Smalltalk?

or is it possible to pass something like

<c: uint32 'dllname':dllFunction pointer+4> to the dll?

regards wolfgang

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Marten Feldtmann-2

Re: memory address of a ByteArray

The address of a Smalltalk object is not fixed - due to the garbage collector. At the time you have received the address you can not be sure, that the address is still valid (when doing the APi call) and the next GC run might has changed the location.

To get rid of this problem you may send the object "makeFixed", which puts the object into fixed space (with all additional problems ...).

Actually it would be interesting to know, if there is a primitive available returning the address of that object - otherwise one must write another primitive to do just that (but that is another story).

It would be (much !) better to work with instances of OSInt8 (or something similar), which are created via "calloc:" if you want to do stuff with low level C API Calls.

wobotzen

Re: memory address of a ByteArray

Hallo Marten

Thanks for the answer

Comments see below.

If you pass objects with pointer or struct into the dll not using asyncCall , this is not a problem, during the dll call there is no garbage collect running

To get rid of this problem you may send the object "makeFixed", which puts the object into fixed space (with all additional problems ...).

This would be used if you pass the address to the dll and return and then keep working with the passed pointer in the dll,

This is not the case in my problem, also FixedSpace is limited and I actually need about 200MB

Actually it would be interesting to know, if there is a primitive available returning the address of that object - otherwise one must write another primitive to do just that (but that is another story).

I already thought about writing a primitive , but then there is a small gap between getting address and passing it to the dll where the garbage collector may do something

It would be (much !) better to work with instances of OSInt8 (or something similar), which are created via "calloc:" if you want to do stuff with low level C API Calls.

That is the current approach, but I need the result later in a ByteArray and this means first allocating 200MB , then create a 200MB ByteArray and then do a copy.

that means I need 400MB peak memory , and the application is already running at the memoryLimit .

regards wolfgang

Marten Feldtmann-2

Re: memory address of a ByteArray

No, there is no gap, when doing it via a primitive.

You get the pointer to the object structure of a ByteArray. You do some calculation to get the real address of the byte array content and call your external dll with that calculated address.

When using the correct macros you can guarantee, that the gc is not fired.

Am 08.02.2013 14:47 schrieb "wobotzen" <[hidden email]>:

Hallo Marten

Thanks for the answer

Comments see below.

The address of a Smalltalk object is not fixed - due to the garbage collector. At the time you have received the address you can not be sure, that the address is still valid (when doing the APi call) and the next GC run might has changed the location.

If you pass objects with pointer or struct into the dll not using asyncCall , this is not a problem, during the dll call there is no garbage collect running

To get rid of this problem you may send the object "makeFixed", which puts the object into fixed space (with all additional problems ...).

This would be used if you pass the address to the dll and return and then keep working with the passed pointer in the dll,

This is not the case in my problem, also FixedSpace is limited and I actually need about 200MB

Actually it would be interesting to know, if there is a primitive available returning the address of that object - otherwise one must write another primitive to do just that (but that is another story).

I already thought about writing a primitive , but then there is a small gap between getting address and passing it to the dll where the garbage collector may do something

It would be (much !) better to work with instances of OSInt8 (or something similar), which are created via "calloc:" if you want to do stuff with low level C API Calls.

That is the current approach, but I need the result later in a ByteArray and this means first allocating 200MB , then create a 200MB ByteArray and then do a copy.

that means I need 400MB peak memory , and the application is already running at the memoryLimit .

regards wolfgang

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Marten Feldtmann-2

Re: memory address of a ByteArray

In reply to this post by wobotzen

I've written some posting about primitives and I think, that this might be interesting for you:

http://schrievkrom.wordpress.com/2010/01/31/vector-arithmetic-primitives-examples/

Am Freitag, 8. Februar 2013 14:47:04 UTC+1 schrieb wobotzen:

I already thought about writing a primitive , but then there is a small gap between getting address and passing it to the dll where the garbage collector may do something