It seems that GCC 4.6.1 gets confused at LTO time when we take the
address of inline functions, so I'm switching them to non-inline
linkage to make it happy.
When link time optimization is enabled, we need to remind the compiler
that we're targeting i586 when linking so it can resolve atomic
operations like __sync_bool_compare_and_swap.
We've already been handling this case in arm.cpp and powerpc.cpp, but
apparently we've never hit this code path in x86.cpp before. Indeed,
I've been unable to come up with a Java source code test that hits it;
it's only come up in Scala-generated bytecode.
Scala occasionally generates exception handler tables with interval
bounds which fall outside the range of valid bytecode indexes, so we
must clamp them or risk out-of-bounds array accesses.
Since we use Thread::code to store a reference to either the method to
be invoked or the current bytecode being executed depending on the
context, we must be careful to switch it back to the bytecode of the
exception handler if an exception is thrown while invoking a method
(e.g. an UnsatisfiedLinkError).
There was a subtle bug in that we were not considering alignment
padding for fields defined in superclasses when calculating field
offsets for a derived class when the superclass(es) were visited by
the bootimage generator before the derived class.
Floats are implicitly promoted to doubles when passed as part of a
variable-length argument list, so we can't treat them the same way as
32-bit integers.
The previous code caused frequent seed collisions for successive calls
to the no-arg constructor, even for single threaded workloads. This
patch should avoid such collisions in both single and multi-threaded
cases.
The previous code caused frequent seed collisions for successive calls
to the no-arg constructor, even for single threaded workloads. This
patch should avoid such collisions in both single and multi-threaded
cases.
