Can GC be BLOCKed?

Can GC be BLOCKed?

[Neal Wang]

Hi all,

    I have a function which cannot be interrupted by GC?  Is there a
way to BLOCK GC when the function is called.  Thanks

Neal

Re: [Caml-list] Can GC be BLOCKed?

[James Woodyatt]

On Nov 29, 2006, at 4:33 PM, Neal Wang wrote:
>
> I have a function which cannot be interrupted by GC?  Is there a  
> way to BLOCK GC when the function is called.  Thanks

We're getting some interesting spam on the OCaml list now.  Just  
after the message above appeared in my inbox, there came the  
following...

On Nov 29, 2006, at 5:22 PM, Rosendo Larson wrote:
>
> The lot is cast into the heap, but the whole disposing there of is  
> of the Lord. There never was a great soul that did not have some  
> divine inspiration.

At first, I thought this was intended to be a serious response to the  
question.

I don't think you can stop collection from happening by explicitly  
blocking it in the GC, but if you know how much memory your function  
will allocate, you might be able to get a winning workaround by  
modifying the GC control parameters for space_overhead and  
major_head_increment.  Use the verbose flag to see if your function  
is triggering the collection phase.


—
j h woodyatt <jhw@conjury.org>
http://jhw.vox.com/

Re: [Caml-list] Can GC be BLOCKed?

[Neal Wang]

Thanks for your help.  But your solution only work for a function
which allocates
  memory of fixed size. Unfortunately, the atomic function, which
cannot be interrupted by GC, read input data from external channels
and the memory needed to store the input data is not determined ahead.
The official interface of GC doesn't not provide a  way to stop GC. Is
there a backdoor such that we can use to stop GC?

   Thanks again
Neal

On 11/29/06, James Woodyatt <jhwoodyatt@mac.com> wrote:
> On Nov 29, 2006, at 4:33 PM, Neal Wang wrote:
> >
> > I have a function which cannot be interrupted by GC?  Is there a
> > way to BLOCK GC when the function is called.  Thanks
>
> We're getting some interesting spam on the OCaml list now.  Just
> after the message above appeared in my inbox, there came the
> following...
>
> On Nov 29, 2006, at 5:22 PM, Rosendo Larson wrote:
> >
> > The lot is cast into the heap, but the whole disposing there of is
> > of the Lord. There never was a great soul that did not have some
> > divine inspiration.
>
> At first, I thought this was intended to be a serious response to the
> question.
>
> I don't think you can stop collection from happening by explicitly
> blocking it in the GC, but if you know how much memory your function
> will allocate, you might be able to get a winning workaround by
> modifying the GC control parameters for space_overhead and
> major_head_increment.  Use the verbose flag to see if your function
> is triggering the collection phase.
>
>
> —
> j h woodyatt <jhw@conjury.org>
> http://jhw.vox.com/
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] Can GC be BLOCKed?

[Tom]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

Hm... There is no way you could do that. If you do not know how much data
your function would allocate, you cannot allocate it in advance. While your
function is being executed, it might occur that the heap is full and that it
needs to be garbage collected before your function could allocate further
data. How do you think this would work if the GC would be disabled?

By the way, it is possible to have C functions that are not interrupted by
GC, but only when they allocate nothing - but whenever some new value is
made, or something is allocated, there might be a need for GC.

 - Tom

[-- Attachment #2: Type: text/html, Size: 613 bytes --]

Re: [Caml-list] Can GC be BLOCKed?

[Richard Jones]

On Thu, Nov 30, 2006 at 04:07:51PM -0800, Neal Wang wrote:
> Thanks for your help.  But your solution only work for a function
> which allocates
>  memory of fixed size. Unfortunately, the atomic function, which
> cannot be interrupted by GC, read input data from external channels
> and the memory needed to store the input data is not determined ahead.
> The official interface of GC doesn't not provide a  way to stop GC. Is
> there a backdoor such that we can use to stop GC?

I can't see how this would work.  The minor heap is a fixed size (32K
or something) and when this is used up, you _have_ to do a minor
collection.

Can you tell us what the problem is that you're trying to solve?

I've only seen two cases where I'd want to stop the GC from running:
(1) During quasi real-time operations (eg. a single frame in a game) --
this can be solved by making the heap large enough and running the GC
at scheduled points.  (2) When the heap is larger than physical RAM --
this is solved using our 'Ancient' module.

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Internet Marketing and AdWords courses - http://merjis.com/courses - NEW!
Merjis blog - http://blog.merjis.com - NEW!

Re: [Caml-list] Can GC be BLOCKed?

[Dmitry Bely]

On 12/1/06, Richard Jones <rich@annexia.org> wrote:

> I've only seen two cases where I'd want to stop the GC from running:
> (1) During quasi real-time operations (eg. a single frame in a game) --
> this can be solved by making the heap large enough and running the GC
> at scheduled points.  (2) When the heap is larger than physical RAM --
> this is solved using our 'Ancient' module.

I have a main program in C that periodically calls an OCaml function
and expects the (near) real time response. So I'd like to avoid gc
inside that function. My current plan is to have another OCaml thread
that is unfrozen just before returning results to C and does the minor
(or major - how to decide which one?) garbage collection. Will it
work?

- Dmitry Bely

Re: [Caml-list] Can GC be BLOCKed?

[Neal Wang]

The problem is not caused by real-time requirement.
Let me explain it in more details:

1. a sqlite3 database is used store mutable objects (objects are
marshaled as strings and stored as BLOB in DB. The objects are very
large and have variant sizes)

2. Weak module is used to cache these objects.

3. Finalise function is used to write back the change of these in
memory objects into the sqlite3 database when GC is called.

The scheme follows  the example in section "Garbage collection" of
ocaml-tutorial.org.

The problem is that:
 When an object is being loaded through an "sql" select stmt, GC is
then invoked to reclaim memory which will in turn call finalise
functions to store some objects into db.  At this moment, the db has
been locked by the select stmt, and the storing procedure fails.  The
problem is due to sqlite3 doesn't provide row level locks.  A simple
solution is to prevent GC from calling finalise functions whenever we
are loading an object into memory.

IMHO, providing a way to disable GC will help a lot in variant
situations.  The only side effect of misuse such a feature is out of
memory exception which does happen even GC is always enabled.

Neal

On 12/1/06, Richard Jones <rich@annexia.org> wrote:
> On Thu, Nov 30, 2006 at 04:07:51PM -0800, Neal Wang wrote:
> > Thanks for your help.  But your solution only work for a function
> > which allocates
> >  memory of fixed size. Unfortunately, the atomic function, which
> > cannot be interrupted by GC, read input data from external channels
> > and the memory needed to store the input data is not determined ahead.
> > The official interface of GC doesn't not provide a  way to stop GC. Is
> > there a backdoor such that we can use to stop GC?
>
> I can't see how this would work.  The minor heap is a fixed size (32K
> or something) and when this is used up, you _have_ to do a minor
> collection.
>
> Can you tell us what the problem is that you're trying to solve?
>
> I've only seen two cases where I'd want to stop the GC from running:
> (1) During quasi real-time operations (eg. a single frame in a game) --
> this can be solved by making the heap large enough and running the GC
> at scheduled points.  (2) When the heap is larger than physical RAM --
> this is solved using our 'Ancient' module.
>
> Rich.
>
> --
> Richard Jones, CTO Merjis Ltd.
> Merjis - web marketing and technology - http://merjis.com
> Internet Marketing and AdWords courses - http://merjis.com/courses - NEW!
> Merjis blog - http://blog.merjis.com - NEW!
>

Re: [Caml-list] Can GC be BLOCKed?

[Chris King]

On 12/1/06, Neal Wang <neal.wang@gmail.com> wrote:
> The problem is that:
>  When an object is being loaded through an "sql" select stmt, GC is
> then invoked to reclaim memory which will in turn call finalise
> functions to store some objects into db.  At this moment, the db has
> been locked by the select stmt, and the storing procedure fails.  The
> problem is due to sqlite3 doesn't provide row level locks.  A simple
> solution is to prevent GC from calling finalise functions whenever we
> are loading an object into memory.

Have you thought about simply postponing the write-back until the
database is unlocked?  If the finalization function finds that the
database is locked, it can place the data to be written into a global
queue.  (This is possible because finalization functions in O'Caml are
allowed to make their data reachable again.)  This queue can then be
flushed when the database is unlocked.  You could easily extend this
to support queueing of any operation by queueing functions instead of
data.

Hope this helps!

- Chris King

Re: [Caml-list] Can GC be BLOCKed?

[Philippe Wang]

Hi.

You can't try to use the thread system to do something like that.

There is a global mutex with OCaml threads !
So a program written in OCaml will not be faster by using threads...

And guess what ? The global mutex does exist because of the existence of 
the GC. And the GC is not threaded...

Well, if ever you manage to do what you said, please let me know.
(If I have well understood your plan, it's clearly impossible)

-- 
  Philippe Wang

Dmitry Bely a écrit :
> On 12/1/06, Richard Jones <rich@annexia.org> wrote:
> 
>> I've only seen two cases where I'd want to stop the GC from running:
>> (1) During quasi real-time operations (eg. a single frame in a game) --
>> this can be solved by making the heap large enough and running the GC
>> at scheduled points.  (2) When the heap is larger than physical RAM --
>> this is solved using our 'Ancient' module.
> 
> I have a main program in C that periodically calls an OCaml function
> and expects the (near) real time response. So I'd like to avoid gc
> inside that function. My current plan is to have another OCaml thread
> that is unfrozen just before returning results to C and does the minor
> (or major - how to decide which one?) garbage collection. Will it
> work?
> 
> - Dmitry Bely

Re: [Caml-list] Can GC be BLOCKed?

[Dmitry Bely]

On 12/2/06, Philippe Wang <lists@philippewang.info> wrote:

> You can't try to use the thread system to do something like that.
>
> There is a global mutex with OCaml threads !
> So a program written in OCaml will not be faster by using threads...

Sure, I know that. But C thread and OCaml thread can run in parallel.
Why not to do gc in another thread when you are in C and there is no
job for OCaml?

- Dmitry Bely

Re: [Caml-list] Can GC be BLOCKed?

[Richard Jones]

On Fri, Dec 01, 2006 at 04:39:26PM +0300, Dmitry Bely wrote:
> On 12/1/06, Richard Jones <rich@annexia.org> wrote:
> 
> >I've only seen two cases where I'd want to stop the GC from running:
> >(1) During quasi real-time operations (eg. a single frame in a game) --
> >this can be solved by making the heap large enough and running the GC
> >at scheduled points.  (2) When the heap is larger than physical RAM --
> >this is solved using our 'Ancient' module.
> 
> I have a main program in C that periodically calls an OCaml function
> and expects the (near) real time response. So I'd like to avoid gc
> inside that function. My current plan is to have another OCaml thread
> that is unfrozen just before returning results to C and does the minor
> (or major - how to decide which one?) garbage collection. Will it
> work?

I guess it'll work - the thing to do is to try it.  I'm wondering why
you need a real time response, and I also hope you're avoiding any
sort of memory allocation on the C side, because malloc and free are
hardly real time functions either.  Many C programmers seem to treat
them as if they were O(1) operations though.

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Internet Marketing and AdWords courses - http://merjis.com/courses - NEW!
Merjis blog - http://blog.merjis.com - NEW!

Re: [Caml-list] Can GC be BLOCKed?

[Philippe Wang]

Dmitry Bely a écrit :

> Sure, I know that. But C thread and OCaml thread can run in parallel.
> Why not to do gc in another thread when you are in C and there is no
> job for OCaml?


Be careful with that...

The global mutex does exist because when the GC occurs, some objects can 
be <<moved>> ! (then their addresses change)
So it's dangerous to compute in parallel...

--
  Philippe Wang

Re: [Caml-list] Can GC be BLOCKed?

[Hendrik Tews]

"Neal Wang" <neal.wang@gmail.com> writes:

   The problem is not caused by real-time requirement.

I would also suggest to solve you problem by postponing the
write-backs using some queue either in ocaml or on the C side.

However:

   IMHO, providing a way to disable GC will help a lot in variant
   situations.  The only side effect of misuse such a feature is out of
   memory exception which does happen even GC is always enabled.

I find it also an interesting idea to be able to block the GC for
certain periods. However, it seems that exceptions are heap
allocated, so you would have to allocate the Out_of_memory
exception statically (not sure if that's possible).

Further, if GC is blocked and the heap is full you can do almost
nothing until the collection is completed. All functions that
catch and reraise exceptions like

   try
     ...
   with
     | x -> release_the_lock(); raise x

would probably not work as expected with an Out_of_memory
exception.

Bye,

Hendrik