corda/src/bootimage.h

75 lines
1.5 KiB
C
Raw Normal View History

2012-05-11 17:43:27 -06:00
/* Copyright (c) 2008-2011, Avian Contributors
2008-11-23 16:58:01 -07:00
Permission to use, copy, modify, and/or distribute this software
for any purpose with or without fee is hereby granted, provided
that the above copyright notice and this permission notice appear
in all copies.
There is NO WARRANTY for this software. See license.txt for
details. */
#ifndef BOOTIMAGE_H
#define BOOTIMAGE_H
#include "common.h"
#include "target.h"
#include "machine.h"
2008-11-23 16:58:01 -07:00
#include <avian/util/math.h>
namespace vm {
class BootImage {
public:
fix Thread.getStackTrace race conditions Implementing Thread.getStackTrace is tricky. A thread may interrupt another thread at any time to grab a stack trace, including while the latter is executing Java code, JNI code, helper thunks, VM code, or while transitioning between any of these. To create a stack trace we use several context fields associated with the target thread, including snapshots of the instruction pointer, stack pointer, and frame pointer. These fields must be current, accurate, and consistent with each other in order to get a reliable trace. Otherwise, we risk crashing the VM by trying to walk garbage stack frames or by misinterpreting the size and/or content of legitimate frames. This commit addresses sensitive transition points such as entering the helper thunks which bridge the transitions from Java to native code (where we must save the stack and frame registers for use from native code) and stack unwinding (where we must atomically update the thread context fields to indicate which frame we are unwinding to). When grabbing a trace for another thread, we determine what kind of code we caught the thread executing in and use that information to choose the thread context values with which to begin the trace. See MyProcessor::getStackTrace::Visitor::visit for details. In order to atomically update the thread context fields, we do the following: 1. Create a temporary "transition" object to serve as a staging area and populate it with the new field values. 2. Update a transition pointer in the thread object to point to the object created above. As long as this pointer is non-null, interrupting threads will use the context values in the staging object instead of those in the thread object. 3. Update the fields in the thread object. 4. Clear the transition pointer in the thread object. We use a memory barrier between each of these steps to ensure they are made visible to other threads in program order. See MyThread::doTransition for details.
2010-06-15 19:10:48 -06:00
class Thunk {
public:
Thunk():
start(0), frameSavedOffset(0), length(0)
{ }
Thunk(uint32_t start, uint32_t frameSavedOffset, uint32_t length):
fix Thread.getStackTrace race conditions Implementing Thread.getStackTrace is tricky. A thread may interrupt another thread at any time to grab a stack trace, including while the latter is executing Java code, JNI code, helper thunks, VM code, or while transitioning between any of these. To create a stack trace we use several context fields associated with the target thread, including snapshots of the instruction pointer, stack pointer, and frame pointer. These fields must be current, accurate, and consistent with each other in order to get a reliable trace. Otherwise, we risk crashing the VM by trying to walk garbage stack frames or by misinterpreting the size and/or content of legitimate frames. This commit addresses sensitive transition points such as entering the helper thunks which bridge the transitions from Java to native code (where we must save the stack and frame registers for use from native code) and stack unwinding (where we must atomically update the thread context fields to indicate which frame we are unwinding to). When grabbing a trace for another thread, we determine what kind of code we caught the thread executing in and use that information to choose the thread context values with which to begin the trace. See MyProcessor::getStackTrace::Visitor::visit for details. In order to atomically update the thread context fields, we do the following: 1. Create a temporary "transition" object to serve as a staging area and populate it with the new field values. 2. Update a transition pointer in the thread object to point to the object created above. As long as this pointer is non-null, interrupting threads will use the context values in the staging object instead of those in the thread object. 3. Update the fields in the thread object. 4. Clear the transition pointer in the thread object. We use a memory barrier between each of these steps to ensure they are made visible to other threads in program order. See MyThread::doTransition for details.
2010-06-15 19:10:48 -06:00
start(start), frameSavedOffset(frameSavedOffset), length(length)
{ }
uint32_t start;
uint32_t frameSavedOffset;
uint32_t length;
} PACKED;
fix Thread.getStackTrace race conditions Implementing Thread.getStackTrace is tricky. A thread may interrupt another thread at any time to grab a stack trace, including while the latter is executing Java code, JNI code, helper thunks, VM code, or while transitioning between any of these. To create a stack trace we use several context fields associated with the target thread, including snapshots of the instruction pointer, stack pointer, and frame pointer. These fields must be current, accurate, and consistent with each other in order to get a reliable trace. Otherwise, we risk crashing the VM by trying to walk garbage stack frames or by misinterpreting the size and/or content of legitimate frames. This commit addresses sensitive transition points such as entering the helper thunks which bridge the transitions from Java to native code (where we must save the stack and frame registers for use from native code) and stack unwinding (where we must atomically update the thread context fields to indicate which frame we are unwinding to). When grabbing a trace for another thread, we determine what kind of code we caught the thread executing in and use that information to choose the thread context values with which to begin the trace. See MyProcessor::getStackTrace::Visitor::visit for details. In order to atomically update the thread context fields, we do the following: 1. Create a temporary "transition" object to serve as a staging area and populate it with the new field values. 2. Update a transition pointer in the thread object to point to the object created above. As long as this pointer is non-null, interrupting threads will use the context values in the staging object instead of those in the thread object. 3. Update the fields in the thread object. 4. Clear the transition pointer in the thread object. We use a memory barrier between each of these steps to ensure they are made visible to other threads in program order. See MyThread::doTransition for details.
2010-06-15 19:10:48 -06:00
class ThunkCollection {
public:
#define THUNK_FIELD(name) Thunk name;
#include "bootimage-fields.cpp"
#undef THUNK_FIELD
} PACKED;
static const uint32_t Magic = 0x22377322;
#define FIELD(name) uint32_t name;
#include "bootimage-fields.cpp"
#undef FIELD
ThunkCollection thunks;
} PACKED;
class OffsetResolver {
public:
virtual unsigned fieldOffset(Thread*, object) = 0;
};
#define NAME(x) Target##x
#define LABEL(x) target_##x
#include "bootimage-template.cpp"
#undef LABEL
#undef NAME
#define NAME(x) x
#define LABEL(x) x
#include "bootimage-template.cpp"
#undef LABEL
#undef NAME
} // namespace vm
2008-11-23 16:58:01 -07:00
#endif//BOOTIMAGE_H