Re: [Dotgnu-libjit] using Libjit with boehm collector

[Aleksey Demakov]

Hi Tommaso,

I am sorry but I don't quite understand what is your question actually.
However I will try to clarify some points with the hope that it might be
helpful.

Libjit uses malloc/mmap to allocate its internal data and the space
for the JIT-ed code. This internal data is not subject to garbage
collection.

The scenario when you have a language with first-class functions
(e.g. Scheme) requires garbage collection of no longer used functions.
Currently this is not going to work with libjit. Once you JIT-compiled
a function the generated machine code is going to stay in the memory
forever. It is impossible to free it. This lets libjit not to care about some
difficult issues such as how to ensure that a function that was freed will
never be called again afterward.

I'm very slowly working on refactoring of the libjit code cache. Ultimately
this should lead to the ability to use pluggable memory managers with
libjit. So if your language or environment makes it possible to ensure
that a freed function is not going to be used again then you could provide
a custom memory manager that allows to free it. Unfortunately I cannot
say when I finish this work as I can allot only very limited time for this.

However if you can tolerate the leakage of JIT-compiled lambdas then
it should be still possible to use libjit for Scheme. I don't understand
your concerns about GC-allocated objects. All such objects should
be allocated by your runtime, not by libjit itself. The pointers to objects
you allocate should be either on the stack so quite visible to the GC or
should be bound to some symbol in the environment. You will need to
have some representation of Scheme environments in your runtime.
I guess it might be some kind of table. Register this table as a GC root.
I would not recommend to register the entire JIT-code area for this.

Regards,
Aleksey


On Thu, Sep 27, 2012 at 11:33 AM, Tommaso Tagliapietra
<address@hidden> wrote:
>> If you keep the bytecode (in GC allocated & reachable memory),
>> and if it is allocated with GC_malloc not GC_malloc_atomic,
>> and if the addresses 0xABCDEF01 or 0x01EFCDAB appearing inside are word 
>> aligned,
>> they will be followed by the GC.
>>
>> I just think that you should understand a bit better how Boehm's GC actually 
>> work.
>> Did you read some documentation (or code comments) about it?
>
> Sure. I know how it's work. And I know that I cannot mix pointer
> allocated with malloc and GC_malloc. Probably I'm doing the wrong
> questions. I'm sorry but English is not my language and I'm unable to
> explain me well.
>
> I'm asking your help because my intention is to use replace bytecoded
> functions with a JIT-ed functions. But, since I've wasted time for a
> lot of other things, I don't want to go in the wrong direction. I
> thought that the DotGNU Portable.NET project was using some strange
> solution to allocate everything with the Boehm collector, and the
> libjit was provided as is, with a standard malloc, to be indipendent
> from other libraries.
>
> Tecnically the interpreter is for a pure object-oriented version of a
> Lisp/Scheme-like language and the collector work very well with my
> solution. Functions are objects allocated with Boehm. However, with
> the new specifications I think will be very slow and then I need a JIT
> compiler.
>
> The finally intention is not to produce a solution, but the faster
> solution with the less amount of allocated memory as possible. This is
> why I'm trying to not use closures. But probably this can be the only
> usefull solution. Yes...I must redesign the architecture.
>
> Now I have only few problems compiling libjit with cygwin, but this is
> another story.
>
> Thank you very much.