Calling StackWatermarkSet::start_processing() in
Deoptimization::revoke_for_object_deoptimization() is redundant. There are
KeepStackGCProcessedMarks on all paths leading to
revoke_for_object_deoptimization() as the call hierarchy below shows.

StackWatermarkSet::start_processing(JavaThread *, enum StackWatermarkKind) : void
....Deoptimization::revoke_for_object_deoptimization(JavaThread *, frame, RegisterMap *, JavaThread *) : void
........Deoptimization::deoptimize_objects_internal(JavaThread *, GrowableArray<compiledVFrame *> *, bool &) : bool
............EscapeBarrier::deoptimize_objects_internal(JavaThread *, intptr_t *) : bool
................EscapeBarrier::deoptimize_objects_all_threads() : bool.................... // has KeepStackGCProcessedMark
................EscapeBarrier::deoptimize_objects(intptr_t *) : bool
....................EscapeBarrier::deoptimize_objects(int, int) : bool.................... // has KeepStackGCProcessedMark