On 8/10/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 8/9/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > a) Fast access to TLS. Yes! Good idea. What you want is a "mov eax, fs[14]" intrinsic for winxp and the equivalent for Linux. It may be a stretch for vmmagic purists to add segment register address arithmetic to vmmagic. Worst case, Harmony could add the segment register facility to Harmony svn.
Exactly, To see why support of calls and calling conventions is also important I propose to try to write a real helper using unboxed types. This way we can prove that the solution does really work, check if the solution is convenient to use and find out what new functionality is needed. Here is very simple example in asm of simple bump-pointer allocation helper's "fast path" for windows: Incoming params: vtable, size Result - a new object reference. main: mov ecx, fs:[14h] // access to TLS mov eax, [ecx + current] // access to 'current' field add eax, size // check if there is enough size to do allocation in thread local buffer cmp eax, [ecx + ceiling] jg slow fast: mov [ecx+current], eax // save new 'current' sub eax, size // reposition to the start of the object mov [eax], vtable // save type info mov objRef eax // save or return result slow: call real new obj helper.. Even this simple helper reveals a lot of features to support: 1) Access to TLS is required. It could be fs:[14h] on Windows or helper call on Linux (depends on kernel (?) ). Even if we have an access to TLS we need to know the offsets of our slots: 'current' and 'ceiling' in example. So we need to have a way to pass these values to JIT. May be a 'private static final' variables in the helper's class with special runtime annotations could be used to pass the values to JIT? 2) Calls support is needed. Both for "slow" helper version and to access TLS. This means also that calling convention support is needed. Runtime level annotations for helper calls could be used here. E.g. create a magic method 'slow_alloc' and teach JIT to call real helper instead of it. Get the calling convention info from annotation (?) 3) Do we really want to expose native regs to Java: EAX, ECX... I vote do not to use them when writing helpers in Java and to allow to JIT to optimize unboxed operations (allocate registers by itself) So, there are a lot of questions to discuss before we can use the code like Alex did (http://issues.apache.org/jira/browse/HARMONY-816) to write this simple helper :) -- Mikhail Fursov