Lines Matching defs:is
5 * This code is free software; you can redistribute it and/or modify it
11 * This code is distributed in the hope that it will be useful, but WITHOUT
14 * version 2 for more details (a copy is included in the LICENSE file that
30 * at the JDI or JDWP level and seen on those levels. Mapping is
32 * to none. Part of that mapping process is filteration, which
56 * Each event kind has a handler chain, which is a doublely linked
86 * If the VM_DEATH callback is active in the BEGIN macro then this
88 * If the VM_DEATH callback is active in the END macro, then this
106 /* Now block because VM is about to die */ \
130 /* Now block because VM is about to die */ \
271 * events, METHOD_ENTRY is always reported first and BREAKPOINT
272 * is always reported last. Here are the possible combinations and
283 * BREAKPOINT (existing) indicates a BREAKPOINT that is set before
284 * the other co-located event is posted. BREAKPOINT (new) indicates
285 * a BREAKPOINT that is set after the other co-located event is
292 * BREAKPOINTs is expensive, e.g., HotSpot.
294 * The policy is now implemented in two phases. Phase 1: when a
295 * METHOD_ENTRY or SINGLE_STEP event is received, if there is an
296 * existing co-located BREAKPOINT, then the current event is
297 * deferred. When the BREAKPOINT event is processed, the event
300 * event where there is not an existing co-located BREAKPOINT,
302 * the METHOD_ENTRY event is deferred. When the SINGLE_STEP event
303 * is processed, the event bag will also contain the deferred
307 * Phase 2: if there is no existing co-located BREAKPOINT, then the
309 * is recorded in the ThreadNode. If the next event for the thread
310 * is a co-located BREAKPOINT, then the first BREAKPOINT event will
314 * For the combination marked p1/p2, part of the case is handled
315 * during phase 1 and the rest is handled during phase 2.
317 * The recording of information in the ThreadNode is handled in
319 * thread is handled in skipEventReport().
421 * the reporting is to be deferred, the event commands remain
422 * in the event bag until a subsequent event occurs. Event is
440 * thread is about to continue, but it may
445 * invoke request can be in place, so there is
539 /* The JVMTI generic event callback. Each event is passed to a sequence of
565 * Note: The "if" is an optimization to avoid entering the lock on every
613 * thread is about to continue, but it may
618 * invoke request can be in place, so there is
697 * there is a pending async exception, StopThread will be
1142 /* The info.clazz is used for both class filtering and for location info.
1143 * For monitor wait event the class filtering is done for class of monitor
1144 * object. So here info.clazz is set to class of monitor object here and it
1145 * is reset to class of method before writing location info.
1184 /* The info.clazz is used for both class filtering and for location info.
1185 * For monitor waited event the class filtering is done for class of monitor
1186 * object. So here info.clazz is set to class of monitor object here and it
1187 * is reset to class of method before writing location info.
1246 * callback protocol. Once the callback table is cleared (above),
1283 * VM. It's not clear this is necessary, but leaving threads
1368 * that is, doesn't free handlers internally created by back-end.
1441 /* This is for BEGIN_CALLBACK/END_CALLBACK handling, make sure this
1442 * is done while none of these callbacks are active.