view src/os/windows/vm/interfaceSupport_windows.hpp @ 14649:f6301b007a16

6498581: ThreadInterruptTest3 produces wrong output on Windows Summary: There is race condition between os::interrupt and os::is_interrupted on Windows. In JVM_Sleep(Thread.sleep), check if thread gets interrupted, it may see interrupted but not really interrupted so cause spurious waking up (early return from sleep). Fix by checking if interrupt event really gets set thus prevent false return. For intrinsic of _isInterrupted, on Windows, go fastpath only on bit not set. Reviewed-by: acorn, kvn Contributed-by: david.holmes@oracle.com, yumin.qi@oracle.com
author minqi
date Wed, 26 Feb 2014 15:20:41 -0800
parents f95d63e2154a
children
line wrap: on
line source

/*
 * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 *
 */

#ifndef OS_WINDOWS_VM_INTERFACESUPPORT_WINDOWS_HPP
#define OS_WINDOWS_VM_INTERFACESUPPORT_WINDOWS_HPP

// Contains inlined functions for class InterfaceSupport

static inline void serialize_memory(JavaThread *thread) {
  // due to chained nature of SEH handlers we have to be sure
  // that our handler is always last handler before an attempt to write
  // into serialization page - it can fault if we access this page
  // right in the middle of protect/unprotect sequence by remote
  // membar logic.
  // __try/__except are very lightweight operations (only several
  // instructions not affecting control flow directly on x86)
  // so we can use it here, on very time critical path
  __try {
    os::write_memory_serialize_page(thread);
  } __except (os::win32::
              serialize_fault_filter((_EXCEPTION_POINTERS*)_exception_info()))
    {}
}

#endif // OS_WINDOWS_VM_INTERFACESUPPORT_WINDOWS_HPP