On 10/11/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Ivan,On 10/11/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote: > > Mikhail, there is GC<>VM interface function exists for this purpose: > > Boolean gc_supports_frontier_allocation(unsigned *offset_of_current, > unsigned *offset_of_limit) { > // Need additional support for object offset in native stubs. > *offset_of_current = field_offset(GC_Thread_Info, tls_current_free); > *offset_of_limit = field_offset(GC_Thread_Info, tls_current_cleaned); > return true; > } Yes, I know. But the main benefit of magics is that JIT does not know the details of the allocation algorithm. The helper is a GC part. You, or any other GC developer, can write any fast-path helper you like and point the JIT to use it. So my proposal is to use known offset in GC_Thread_Info and hardcode it into the helper code. Another solution is to initialize these offsets as final static fields during helper class initialization using JNI accessor to GC natives.
Ahh, I see now. I was thinking about GC independent helper. You are right.
1. VM exactly knows where the GC_Thread_Info is in TLS and using this > offsets can obtain current allocation position and its limit. It seems > that the information should be also propagated to JIT if you want to > implement the helper inlining. Yes, this is not the problem. In the example I wrote the TLS.getGCThreadLocal() does the same.
ok
2. You should not care about cleaned with uncleaned memory as it just > GC v4.1 specific optimization. Fast path should deal with current and > limit as in gc_supports_frontier_allocation(). This is the helper for GCv4.1. JIT does not care if memory cleaned or not. JIT does not care if you use bump-pointer of free-list allocation. So it's up to you if too keep it.
ok
3. This is just VM<>GC native interface function. There is no other > parameters passed here currently. Yes, it's enough to support GCv4.x and GCv5. But is it OK for MMTK collectors? The main idea is to make JIT as independent as possible.
Let's ask Weldon here.
4. No need, see above (in 2). Ok, if you do not need this functionality in the fast path we can remove it.
Well, if we talk about GC specific helpers, I would prefer to keep it :)
5. Excellent idea! I thought about it. This optimization can be much > valuable. > > More issues to deal with. > > Current native helper which is called from managed code to allocate a > object has one problem. It should call <clinit> for uninitialized > classes. I was working with it some time ago, but the change was too > intrusive and had negative performance impact. It was decided to do > this latter. I think we should think about it again now. I thought that the problem is already solved on the JIT side?! That was a real headache for me to synchronize check sums and map edge profiles from the IR with class initialization helpers to IR without it in server mode.
It is possible that I have outdated information.
I suggest before compiling fast path code check whether class is > initialized and not finalizible. Depending on the results we can > produce different fast (or generic) code paths. Finalization issue is clean. But I see no improvements in the fast path related to the class initialization.
If we still has issues with initialization we could do the following: 1. If class in already initialized when we compile the allocation code we can forget about the initialization. 2. If it is not initialized yet, we can insert required initialization check right before usual allocation fast path.
-- Mikhail Fursov
-- Ivan Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
