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.
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.
Previously, we only seemed to define sysroot for MacOS, not iOS, yet
we reference $(sysroot) in both cases. This ensures it is defined in
both cases as well.
Since we can't predict what warnings future compilers will emit, and
most people just want to build Avian without some new warning tripping
it up, we now omit -Werror unless requested via the "use-werror=true"
option to make. Note that we pass "use-werror=true" in test/ci.sh to
ensure Travis alerts us to new warnings as they appear.
BTW, sorry about the unrelated whitespace changes in this patch; I've
got Emacs set up to fix whitespace "problems" on save, and those are
what it found.
The tower of patches and hacks grows higher. Ideally, we'll just drop
support for JDK 7 soon and clean this mess up a bit, but TravisCI
still hasn't gotten the memo that it's dead, so we muddle onward.
I've tested this on Windows, but not yet Linux or OS X. Wanted to get
a PR before I move on to that.
- handle sim flag to better distinguish between ios simulator / ios
- added ios_deployment_target to set ios min version
- default to 64 bit build for iOS
This option specifies that the test classes should be AOT-compiled
along with the class library, which allows us to test that everything
works in AOT-compiled form as well as JIT-compiled form. This is
primarily motivated by the need to test d906db6 (support for
AOT-compilation of Java 8 lambda expressions).
Note that I had to tweak Misc because it tested something that
couldn't be done in an AOT build without a lot of extra work, and
SystemClassLoader.getPackage because it was returning null when the
requested package could not be populated with JAR manifest metadata.
Technically, we probably *should* return null for packages that don't
exist at all (in the sense that no classes have been loaded from such
a package), but tracking that kind of thing seems like more trouble
than it's worth unless someone complains about it.
These expressions are tricky because they rely on invokedynamic, which
normally implies runtime code generation. However, since lambdas
don't actually use the "dynamicness" of invokedynamic, we can convert
them into static calls to synthetic classes at compile time.
Since I had already written code to synthesize such classes in Java
and I didn't want to rewrite it in C++, I needed to add support for
running Java code to the bootimage generator. And since the primary
VM used by the generator is purpose-built to generate AOT-compiled
code for a specific target architecture and is not capable of
generating or running JIT-compiled code for the host architecture, I
added support for loading a second, independent, host-specific VM for
running Java code.
The rest of the patch handles the fact that each method compilation
might cause new, synthetic classes to be created, so we need to make
sure those classes and their methods are included in the final heap
and code images. This required breaking some giant code blocks out of
makeCodeImage into their own methods, which makes the diff look
scarier than it really is.
This is a bunch of commits squashed into one per Josh's request.
add dynamicTable field
add invokedynamic instruction
add defaultDynamic bootimage field
add dummy invokedynamic support in bootimage-generator
add defaultDynamic thunk
check dynamicTable offset
comment defaultDynamicThunk to fix unused function
comment defaultDynamicThunk to fix unused function
add dynamicTable / dynamicIndex stuff
comment dynamicIndex and dynamicTable
add invokedynamic instruction impl
stub out addDynamic
unstub addDynamic
don't allow tail calls in invokedynamic
implement stub JVM_GetTemporaryDirectory method
(build broken) begin add InvokeDynamicTest
Revert "(build broken) begin add InvokeDynamicTest"
This reverts commit 77f9c54e32ac66d0803eeab93e4a10d3541987a8.
add InternalError
add URLClassPath.c for openjdk-src builds
implement stub JVM_KnownToNotExist and JVM_GetResourceLookupCache methods
intercept open0 / open for openjdk
add basic java/lang/invoke stubs
remove non-public java/lang/invoke classes
fix invokedynamic example building
<wip debugging>
Someone on the Google Groups site asked how to set up an Eclipse
project with Avian classpath. This patch creates the descriptor
that you can you use to do that at `$(build)/eclipse/jdk/avian.ee`.
The descriptor includes the Avian version, platform, architecture,
and build options to allow for multiple versions to exist side by
side. Users can import the descriptor into Eclipse via:
Window >> Preferences >> Java >> Installed JREs >> Add >> Execution
Environment Description
Once the descriptor is imported, Avian can be used just like any other
JVM installation for Eclipse projects. Personally I use this in
conjunction with Eclim to gain code completion for Avian in vim.
The new targets also create symlinks to loosely mimic OpenJDK's
filenames and folder layout:
build/linux-x86_64-tails-continuations/eclipse/jdk/
├── avian.ee
├── bin
│ └── java -> ../../../avian
├── jre
│ └── lib
│ └── rt.jar -> ../../../../classpath.jar
└── src -> ../../classpath
Annoyingly, Eclipse for some reason expects this layout to exist
even though the descriptor format has required parameters for
specifying these locations. I suppose that other software may
look for this "standard" layout in a JVM installation so it may be
generally useful.
These artifacts are only built if the platform is one of `windows`,
`linux`, or `macosx`. The symlinks might not actually work at all on
Windows, I'm not sure how things like cygwin/msys handle that and I
do not have the means to test it. If they do not work a fallback
for windows might be to actually copy the files instead of symlinking.
I realize this can be done outside of the makefile but it seemed
useful to put it here to gain access to the information about the
build location, platform, architecture, and other build options.
For the record, this contribution is my original work and is released
under the same license that Avian uses, found in the license.txt
file in this repository.
80ce92a introduced a regression which caused the Cygwin build to fail,
since it tried to set platform=$(build-platform) when calling make
recursively, and platform=cygwin is rejected by the makefile.
Instead, we need to use $(bootimage-platform), which normalizes
"cygwin" and "mingw32" to "windows".
