I've attached combined JIT+VM patch to JIRA. The test failed before passes now. VM-guru, please check VMEXPORT Boolean vm_helper_is_gc_interruptible(VM_RT_SUPPORT f) method in this patch.
On 4/13/07, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
2007/4/13, Mikhail Fursov <[EMAIL PROTECTED]>: > Rana, > thank you for the fast update. > I'll integrate this function usage into JIT and report if the problem I have > disappeares today. > > >>BTW, how does the jit knows which helpers throw exceptions? > JIT generates stack info for every call instruction. So we can > unwind stack frame from every call. > Actually this is not enough: JIT must generate stackinfo for every push inst > also to handle SOE correctly. But this is one of the TODO list items. > > > Another problem with helper calls I know is their calling conventions. > Now the calling convention of every helper is hardcoded to JIT. > I think it worth creating another JIRA to solve the problem one day. Today I > know no bugs about it, so it's design only issue. There is one already: HARMONY-2702. Actually Jitrino provides such interface internally, CompilationInterface::getRuntimeHelperCallingConvention(), so fix should be easy enough (yet is blocked by HARMONY-3553). > > > On 4/13/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > > > Yes, that make sense. I'll wait a bit to see if Mikhail has any more > > suggestions and change it to is_gc_interruptible. > > > > On 4/12/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > > Agree that this information better be provided by VM than JIT internals. > > > > > > Rana, Thanks for the quick work. A minor comment: > > > > > > The interface name might be better use "has_gc_safepoint" or > > > "is_gc_interruptible" than "is_suspension_point", since the helper is > > > a function (not a point), and "suspension" is implementation detail. > > > > > > Thanks, > > > xiaofeng > > > > > > On 4/13/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > > > Mikhail, > > > > I extended the vm-jit interface with a function: > > > > boolean vm_is_helper_suspension_point( VM_RT_SUPPORT f) > > > > > > > > and attached it to your JIRA. > > > > > > > > Right now it returns true for almost every helper. But you may want > > > > to update this instead of hardcoding in the jit. At some point, we > > > > need some analysis to determine which helpers are interruptible. > > > > > > > > BTW, how does the jit knows which helpers throw exceptions? > > > > > > > > Rana > > > > > > > > > > > > > > > > On 4/11/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > > > > > On 4/12/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > On 4/11/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > > > > > > On 4/12/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > > > > > > > A silly question possibly. But other than inlined fastpaths, > > why not > > > > > > > > gcm treat all helper calls as interruptible? > > > > > > > > > > > > > > I think this needs case by case study to decide which ones can > > be > > > > > > > interruptible. In most cases, the helper is only an extension of > > a > > > > > > > certain bytecode operation, which can be virtually treated as a > > > > > > > bytecode (or part of a bytecode semantics). Normally, the > > safepoint > > > > > > > can be before or after it, but not in middle of it. If we think > > of the > > > > > > > stack map info, the helper itself may not stand for a formal > > method > > > > > > > frame for GC or exception handling. > > > > > > > > > > > > This is a good way to look at helper calls. My point, > > however, was > > > > > > not really that helper calls should be interruptible. But that > > other > > > > > > than the fastpath for which the JIT sees the IR, why not treat the > > > > > > calls themselves as ineligible for code motion etc. like other > > > > > > operators with side effects? Is the cost too high? > > > > > > Implementing the interface extension is not hard for the VM, but > > looks > > > > > > like implementation dependant info passed from the VM to the JIT. > > > > > > > > > > > > Here is more details: > > > > > The example of a helper that can be moved by GCM are number > > conversion helpers. > > > > > 'i2d' never throws exceptions and this knowledge is hardcoded in > > HLO. On the > > > > > other hand this HIR opcode is translated into LIR vm-helper call, so > > instead > > > > > of simple Java opcode it becomes a > > > > > call. I can hardcode which vm-helper call is interruptable and which > > is > > > > > not on the > > > > > JIT side, but think retrieving this information from VM is a better > > solution. > > > > > Another example of uninterruptable vm-helper is > > > > > TLS accessor. This helper is placed into the middle of the inlined > > > > > 'alloc' helper body because 'alloc' reqires TLS access. > > > > > Now managed<->unmanaged convertion checker in GCMap pass has > > hardcoded > > > > > knowledge that TLS access will never be suspended. > > > > > > > > > > JET compiler uses different code then OPT and maintains special > > > > > GC-bitmasks for object operands runtime. > > > > > The per-call gc-mask maintainance is not free and can also be > > > > > optimized if VM provides a method to describe which call is real > > > > > suspension point and which is not. > > > > > > > > > > > > > > > > > > > > + Suspension and exception throwing are different attributes. SOE > > can be > > > > > thrown even if method is not a suspension point. So JIT must prepare > > stack > > > > > info for every call it generates to be able to unwind the frame. > > > > > > > > > > -- > > > > > Mikhail Fursov > > > > > > > > > > > > > > > > > > -- > > > http://xiao-feng.blogspot.com > > > > > > > > > -- > Mikhail Fursov >
-- Mikhail Fursov
