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
