[m-rev.] for review: stand-alone interface and non-C grades

[Paul Bone]

On Thu, Dec 04, 2014 at 08:58:16PM +1100, Julien Fischer wrote:
> On Thu, 4 Dec 2014, Paul Bone wrote:
>> On Thu, Dec 04, 2014 at 08:23:28PM +1100, Julien Fischer wrote:
>>>
>>>
>>> On Thu, 4 Dec 2014, Paul Bone wrote:
>>>
>>>> On Thu, Dec 04, 2014 at 04:29:59PM +1100, Julien Fischer wrote:
>>>>>
>>>>> For review by anyone.
>>>>>
>>>>>
>>>>> Stand-alone interfaces and non-C grades.
>>>>>
>>>>> Clarify the situation with stand-alone interfaces and non-C grades.  The
>>>>> documentation currently says that they are not currently supported for the
>>>>> non-C grades, which is inaccurate.  They are not actually required for the Java
>>>>> and C# backends.  The may however be needed for Erlang.
>>>>>
>>>>
>>>> I'll double check the situation regarding the new thread pool code in the
>>>> Java grade.
>>>
>>> The thread pool code shouldn't have anything to do with runtime
>>> intialisation though should it?T
>>
>> The thread pool needs to be initialised.  it's true that this can happen
>> when it's first used however that's why I mentioned the specific issue
>> below.
>>
>>>> I beleive that if your program uses threads, specifically anything
>>>> that uses semaphore.m it assumes that your Mercury code is being
>>>> executed by a Mercury thread.
>>>
>>> I'm don't follow you -- when would Mercury code not be executed by
>>> a Mercury thread?
>>
>> When you call into it from your application using one of the application's
>> threads, including the initial thread (I think, this is what I need to
>> check).
>
> Ah, I think I see: so I if I call exported Mercury predicates from two
> different Java threads they use the same thread pool?

No, that's not it.

If a thread blocks on a semaphore (java/runtime/Semaphore.java) then the
Semaphore notifies the current thread (java/runtime/MercuryThread.java) that
it has been blocked so that the thread pool knows how many active and
blocked threads there are.  If there are fewer than P active threads, then
the pool is allowed to spawn new threads, because we expect that physical
processors are now available.  The thread pool otherwise avoids spawning
threads to avoid using more memory than necessary, potentially creating
embrassing parallelism.  Although as Peter Wang demonstrated recently, Linux
can handle a rather large number of pthreads.  The Oracle JVM used to use
green threads, but for a long time it's been using native threads.

In checking the details I've looked up the code.  The code is actually safe
it checks if the thread in question is a MercuryThread and if not it does
nothing, that is it doesn't notify the thread, the semaphore still works
correctly.

>> Also now I think about it, how are module initialisers and finalisers called
>> on the Java backend when the Mercury code is used like this?
>
> Mercury module initializers are called from static initialization blocks
> in Java.

Cool.

> Mercury module finalizers are registered with the JavaInternal class
> in the runtime and can be run by calling jmercury.runtime.JavaInternal.run_finalisers().
>

It looks as if some things, including the thread pool, arn't initalised if
you use Mercury as a library.  See JavaInternal.runMain() and the
JavaInteral constructor.  Static initialisation is probably the best fix.

-- 
Paul Bone