Previously, I was lazily initializing this field in addDynamic, but
that only worked if a thread compiles an invokedynamic expression
prior to the first time it executes one, which is not always the case.
This is a bit tricky to write a simple test case for, since it
involves multiple threads, but I've tested it with a big, lambda-heavy
app and it fixes an otherwise consistent crash there.
The main issue was that offsets for GC roots on the stack were being
miscalculated because invokedynamic bootstrap methods are invoked as
static methods but were not being flagged as such.
Also, I forgot to initialize MyThread::dynamicTable in the constructor
(and why the hell doesn't `gcc -Wall` warn me about stuff like that?)
We now detect both metafactory and altMetafactory lambdas when
bootimage-compiling invokedynamic instructions, as well as make
allowance for the same lambda being invoked by multiple invokedynamic
instructions (as is the case for Serializable lambdas).
For lambdas that implement java.io.Serializable, the compiler emits
calls to LambdaMetaFactory.altMetafactory, not
LambdaMetaFactory.metafactory, so I've provided a stub implementation
that ignores that currently ignores the extra parameters it receives.
This also fixes a bug in compiling lambda glue code for lambdas that
take longs and/or doubles.
Trace.java fails randomly on Travis, but we've never been able to
reproduce or debug the failure elsewhere, so now we skip it if we
detect the suite is running on Travis.
Per a recent bug report in the hello-ios project, we found that
bootimage-generator would abort with no explanation if it encountered
a lambda invocation and the `-hostvm` option was unspecified. This
commit ensures that a helpful message is printed before exiting.
Apparently the MinGW header files don't declare it, despite it being
part of liblphlapi.a. More confusingly, it didn't break anything for
64-bit builds because the compiler used an implicit declaration that
matched the link-time symbol name. Alas, no such luck for 32-bit
builds, since the implicit declaration was not annotated with the @48
stdcall argument stack size, so the build died at link time.
The title is not strictly required, but it's useful metadata, and part of the recommended license template text (see http://choosealicense.com/licenses/isc/ and https://opensource.org/licenses/isc-license)
As for the filename, lowercase is fine, but since this project already uses an uppercase README as customary, using the same standard for the LICENSE file seemed to make sense.
Prior to this commit, we had a little bit of "cleverness" wherein we
recursively invoked make to determine which of the .class files in the
class library were out of date with respect to their .java files. We
did this to avoid asking javac to recompile everything every time.
The problem with that is when building against an alternative class
library (e.g. OpenJDK or Android), we use a combination of classes
from the alternative library and some of the built-in Avian classes
(e.g. java/lang/invoke/MethodHandle, which is very closely tied to the
VM). This confuses the build process, since some of the classes were
taken from an external jar, and some of them were built from source.
The tricky bit is that, depending on the relative timestamps of the
extracted .class files and the .java source files, you might never see
the problem. That's why I couldn't reproduce this when it was first
reported a few months ago: my source files were newer than the .class
files from the OpenJDK jars I was using, so the Avian versions were
built and used as intended. It was only later when I used a newer
OpenJDK that I hit the problem.
Anyway, I've removed the cleverness. If this causes an unreasonable
regression in (re)build times, we can try to reintroduce it in a way
that avoids the above problem, but for now simpler is better.
Although some people still use MSYS to build Avian (e.g. the
avian-pack project), I'd rather not support it officially, and the
instructions in the README.md are outdated anyway. This will
hopefully encourage new users to use Cygwin instead, which is less
likely to break without me noticing since that's what I use myself.
Per a recent request for help on the Google group, I spent some time
this past weekend trying to debug the MSYS build. The conclusion I
came to is that MSYS is not worth supporting anymore. The most recent
release is almost three years old, and I've been unable to find any
variant with a 64-bit-target compiler that will actually install. If
someone else cares enough about building Avian on MSYS to maintain it
themselves, patches are welcome.
Meanwhile, let's all just use Cygwin. Perhaps someone will build a
cool package manager on top of WSL and suddenly make both Cygwin and
MSYS obsolete.
