[Caml-list] GC and preventing data relocation

[Caml-list] GC and preventing data relocation

[Markus Mottl]

Hello,

I have just started to integrate a new feature into PCRE-OCaml that
would allow callbacks ("callouts") during pattern matching. However,
if I'm not mistaken, there is a severe problem for which I don't know
any good workaround:

Among other things, my C-function gets a string value and passes it to
a C-library for pattern matching together with information on what to
do in the case of "callouts" in the regular expression. If the C-engine
detects such an indicator, my wrapper code is called again and receives
the callout data (e.g. an array of callout closures provided by the
OCaml-code).

When my code calls OCaml again via one of those closures, this may,
of course, trigger the GC. Unfortunately, the GC may feel like moving
data around, e.g. the string which is currently still in use by the
C-engine of the library. Needless to say that this may cause trouble!
Copying the string internally into the C-heap to prevent this would be
really bad due to performance/memory reasons...

Since there is no way for me to tell the C-library to continue with a
new location of the string, I'd like to know whether there is any way
to prevent the GC from moving specific data?

Best regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GC and preventing data relocation

[Christopher Quinn]

Markus Mottl wrote:
> Since there is no way for me to tell the C-library to continue with a
> new location of the string, I'd like to know whether there is any way
> to prevent the GC from moving specific data?
> 
> Best regards,
> Markus Mottl
> 

i looked into this and came up with:
a) if you have C-heap struct specific to each invocation, register the 
field holding the string pointer as a caml root, deregister it on 
completion. but that is more overhead.

b) add a CString_tag to the set of value tags, modify the compactor() 
routine to take acccount of it, and change the tag of a regular string 
at runtime.
unfortunately this scheme greatly inconveniences the design of the 
compactor and would likely slow it down.

c) differentiate static from dynamic 'chunks' and allocate strings 
from static chunks. this still allows GC to be done on static values 
but is easily integrated into the compactor.
interface: val Cstring.make: int -> string ... as normal.
i have a patch for this if you are interested.

it is all down to the compactor and the current version treats values 
indifferently.

- chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GC and preventing data relocation

[Markus Mottl]

On Thu, 20 Mar 2003, Christopher Quinn wrote:
> i looked into this and came up with:
> a) if you have C-heap struct specific to each invocation, register the 
> field holding the string pointer as a caml root, deregister it on 
> completion. but that is more overhead.

I don't quite understand this solution. How should this prevent the
string from being relocated if the string was allocated in the OCaml-heap?

> b) add a CString_tag to the set of value tags, modify the compactor() 
> routine to take acccount of it, and change the tag of a regular string 
> at runtime.
> unfortunately this scheme greatly inconveniences the design of the 
> compactor and would likely slow it down.

And wouldn't be particulary portable...

> c) differentiate static from dynamic 'chunks' and allocate strings 
> from static chunks. this still allows GC to be done on static values 
> but is easily integrated into the compactor.
> interface: val Cstring.make: int -> string ... as normal.
> i have a patch for this if you are interested.

This solution is also not portable and inconvenient for the user,
because he has to allocate strings in this specific way.

Hm, seems we are out of luck here?

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GC and preventing data relocation

[Christopher Quinn]

Markus Mottl wrote:
>>a) if you have C-heap struct specific to each invocation, register the 
>>field holding the string pointer as a caml root, deregister it on 
>>completion. but that is more overhead.
> 
> 
> I don't quite understand this solution. How should this prevent the
> string from being relocated if the string was allocated in the OCaml-heap?

it wouldn't, but at least the pointer to it is changed also. and the 
assumption i made was that the glue code knows where it is keeping its 
pointer to the string.

> 
> 
>>b) add a CString_tag to the set of value tags, modify the compactor() 
>>routine to take acccount of it, and change the tag of a regular string 
>>at runtime.
>>unfortunately this scheme greatly inconveniences the design of the 
>>compactor and would likely slow it down.
> 
> 
> And wouldn't be particulary portable...

what 3rd party modification to the distributed caml runtime is!?

- chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GC and preventing data relocation

[Markus Mottl]

On Fri, 21 Mar 2003, Christopher Quinn wrote:
> Markus Mottl wrote:
> >I don't quite understand this solution. How should this prevent the
> >string from being relocated if the string was allocated in the OCaml-heap?
> 
> it wouldn't, but at least the pointer to it is changed also. and the 
> assumption i made was that the glue code knows where it is keeping its 
> pointer to the string.

Well, the glue code can surely know, but unfortunately things are more
complicated, because the C-library can't:

  OCaml
    |
    +--> C-glue code
            |
            +--> C-library
                   |
           +-----> +--> C-glue code (via "callout" function pointer)
           |              |
           |              +--> OCaml (callback)
           |
      problem is here

Once the opaque C-library runs off with a given pointer to a string,
it may generate tons of internal datastructures that depend on this
specific location. There is just no way for me to tell the C-library
to continue elsewhere, because the C-library called me (the glue code)
before the OCaml-callback, not vice versa, and just expects me to return.

Well, I could ask the author of the C-library to add a feature that
adds offsets at each step to dependent pointers to accommodate for
relocations. But he'll probably rather kill me than rewrite 7 KLOCs of
low-level code... ;-)

> >And wouldn't be particulary portable...
> 
> what 3rd party modification to the distributed caml runtime is!?

Indeed...

Regards,
Markus Mottl

--
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GC and preventing data relocation

[Damien Doligez]

On Thursday, March 20, 2003, at 04:16 PM, Markus Mottl wrote:

> Since there is no way for me to tell the C-library to continue with a
> new location of the string, I'd like to know whether there is any way
> to prevent the GC from moving specific data?

In the current implementation (and in the foreseeable future), if your
string is in the major heap, then only the compactor can move it.
You could try to disable the automatic compaction (by setting
max_overhead to 1 million) during the callback, restoring the
original setting when you get out of the callback.  You'll have
to tell your users that they must not call Gc.compact nor change
max_overhead during the execution of the callback function.

You will also have to correctly manage the case where the callback
function raises an exception...

If the string is in the minor heap, you know it's a short string
and you can (for example) copy it into a buffer pre-allocated in
the C heap.

-- Damien

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GC and preventing data relocation

[Markus Mottl]

On Fri, 21 Mar 2003, Damien Doligez wrote:
> In the current implementation (and in the foreseeable future), if your
> string is in the major heap, then only the compactor can move it.
> You could try to disable the automatic compaction (by setting
> max_overhead to 1 million) during the callback, restoring the
> original setting when you get out of the callback.  You'll have
> to tell your users that they must not call Gc.compact nor change
> max_overhead during the execution of the callback function.

Well, I always get headaches when relying on users reading manuals ;-)

> You will also have to correctly manage the case where the callback
> function raises an exception...

Of course! Luckily, the C-interface of OCaml is quite convenient and
allows one to handle such cases without problems.

> If the string is in the minor heap, you know it's a short string and
> you can (for example) copy it into a buffer pre-allocated in the C heap.

Unfortunately, this won't work, because the callback may again call the
C-code, either overwriting the buffer or requiring me to write my own
memory management. I don't think the latter is worthwhile so I'll just
dynamically allocate buffers as required.

Regards,
Markus

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GC and preventing data relocation

[Nicolas Cannasse]

> > If the string is in the minor heap, you know it's a short string and
> > you can (for example) copy it into a buffer pre-allocated in the C heap.
>
> Unfortunately, this won't work, because the callback may again call the
> C-code, either overwriting the buffer or requiring me to write my own
> memory management. I don't think the latter is worthwhile so I'll just
> dynamically allocate buffers as required.

So, what about running a full_major, that should empty the minor heap and
move your string into the major heap.
Or else, explicity create a major heap ocaml block and copy the string into
it ( in not already in major heap ).

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GC and preventing data relocation

[Markus Mottl]

On Mon, 24 Mar 2003, Nicolas Cannasse wrote:
> So, what about running a full_major, that should empty the minor heap and
> move your string into the major heap.
> Or else, explicity create a major heap ocaml block and copy the string into
> it ( in not already in major heap ).

A full major collection at each call to a string matching function? This
would really be out of the question for performance reasons.

After some more thinking I have come to the conclusion that it is
probably best to just copy the string to the C-heap if callbacks are
possible and do matching there.

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners