On 10/12/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
On 10/11/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > GC, VM gurus! > > The problems I see: > > 1) The problem: GC helper must know GC_Thread_Info struct offsets. This is no problem. I designed fast-path allocation that is independent from specific GC in GCv5, I have no GC_Thread_Info because the name is confusing. I use Allocator structure for it, which is defined as: typedef struct Allocator{ void *free; void *ceiling; Block *alloc_block; Space* alloc_space; GC *gc; void* thread_handle; /* This thread; */ }Allocator; The values of the fields offset are constant; and for fast path, only free and ceiling are needed actually.
Ok, no new functionality is required to write a fast-path helper for gc-v5.
2) The problem: Where to keep GC magic code? This code is GC specific and > must be available for bootstrap classloader. > JIT can know all the details which magic code to inline (the helper type, > the helper signature) from its properties (see opt.emconf file for example) The code definitely should be part of GC since it's developed by GC developer. The contract between GC and VM (not JIT normally) can be accomplished in way similar to current RT helper support (not the same of course). We can put all the helpers into a single class (the contract interface), so that each GC implementation can inherit the class with its implementation. The non-overriden (or implemented) methods will not be inlined.
Xiao-Feng, do I get it right? The "contract interface" is: The implementation of helpers are static methods with known names. Every GC puts the implementation of its helpers into the separate package/class and JIT knows the name of the package/class from a properties. Or do you mean something different?
3) The problem: Is the signature for gc_alloc method : gc_alloc(int objSize, > int allocationHandle) is universal for all GCs? > I think it's not. But we can extend JIT with different signatures support if > needed. This interface has a third parameter of TLS for gc. Are we going to remove it?
Yes, because TLS value is needed for different helpers. So, the better solution could be is to have TLS.getAddress() as magic. On the other hand, I prefer to ignore the allocationHandle parameter
in fast path. We don't really need it anyway.
Storing type info into object image is a part of the object initialization. This way old slow helpers work. Do you propose to change the old slow interface and ask JIT to initialize object image?
4) The new magic method is proposed, line J21: > org.apache.harmony.vmhelper.native.Utils.memset(tlsNewFreeAddr, > bytesToClean, 0); What magics you want to implement are completely your freedom. :-) But personally I prefer not having memset in magics. It's way too system dependent. If we want it for GCv4.1 performance reason, we can keep this kind of non-essential methods into another extra interface.
No, it's not mine (as JIT developer primary) freedom. We are discussing VM extension for magics and must avoid any unnecessarily operations. Why do you think memset is bad and system dependent primitive?
5) The magic code in does not contain 'finalizable' check. > JIT can do this check during the compilation and do not generate the fast > path. This is another option to pass to JIT from GC. Yes, this is good. Let's drop the allocationHandle. I am not using it in GCv5.
Here I have the same question as above. How do you initialize a raw object image? (I'll take a look by myself, it's very interesting problem) -- Mikhail Fursov