From ingo_weinhold at gmx.de  Fri Mar 26 13:10:28 2010
From: ingo_weinhold at gmx.de (Ingo Weinhold)
Date: Fri, 26 Mar 2010 21:10:28 +0100
Subject: hotspot building
In-Reply-To: <9cf4bb560912211418j2a7cc02cue5c553f51cc2a651@mail.gmail.com>
References: <9cf4bb560912211418j2a7cc02cue5c553f51cc2a651@mail.gmail.com>
Message-ID: <20100326211028.380.2@knochen-vm.localdomain>

On 2009-12-21 at 23:18:19 [+0100], Andrew Bachmann 
<andrewbachmann at gmail.com> wrote:

Having seen no commits since, I thought I check out things and see, if I can 
be of any help...

> Sorry for the lull in activity recently.  My hard drive got corrupted
> and I had a house guest, so things got delayed.  But now I'm happy to
> announce that I've managed to get the libjvm.so and related files
> building completely on Haiku.  Here's a blog entry detailing the steps
> to reproduce what I've done so far:
> 
> http://www.haiku-os.org/blog/andrewbachmann/2009-12-21_openjdk_hotspot_libjvmso_built_haiku

Unfortunately when following the build instructions (with modified working 
directory and bootdir paths) in the "make" step I reproducibly encounter a 
crash of the compiler. I originally tried a current Haiku trunk revision, 
but the same happens with the alpha 1 release.

The crash happens when compiling 
"hotspot/src/share/vm/compiler/abstractCompiler.cpp" (or after touching the 
output file the following source) in cc1plus, function linemap_lookup(). I 
tracked the problem as far as I could without building gcc myself. 
Apparently when loading the preprocessed header file 
incls/_precompiled.incl.gch cc1plus also updates (reads) a global variable 
line_table whose value is passed later to linemap_lookup(), leading to the 
crash.

Since the blog post doesn't mention any such problem, I'm wondering why I 
can reproduce it reliably both under real hardware and emulation. So far 
I've used the same working directory for all attempts, so I wouldn't rule 
out that a file corruption is somehow to blame, but I don't quite see how a 
corrupt header file would make it through the header precompilation process 
and even lead to a corrupt output file. Will try a fresh checkout anyway. 
Any other hints are welcome.

> Next I am working on getting the jdk make files in order and adding in
> the haiku awt and other support classes.  In the past, we used jikes
> to compile these classes.  Unfortunately, even the most recent version
> of jikes is now five years old and can't handle the generics that are
> around now.  So, we need to use a different solution.
> 
> I know Michael was looking into this issue a little while ago.  Also,
> I believe we can use remote hosting to compile the files, as well.

Isn't it possible to just compile the java source files once on another 
platform and use the generated class files (or jars) under Haiku? The only 
thing needed initially is to bootstrap the JVM and the compiler. Thereafter 
you have a native compiler. Or do I miss something?

CU, Ingo

From andrewbachmann at gmail.com  Mon Mar 29 14:07:49 2010
From: andrewbachmann at gmail.com (Andrew Bachmann)
Date: Mon, 29 Mar 2010 14:07:49 -0700
Subject: hotspot building
In-Reply-To: <20100326211028.380.2@knochen-vm.localdomain>
References: <9cf4bb560912211418j2a7cc02cue5c553f51cc2a651@mail.gmail.com>
	<20100326211028.380.2@knochen-vm.localdomain>
Message-ID: <9cf4bb561003291407tdd6ac12ibe7feac80e0267de@mail.gmail.com>

Hi Ingo,

Thanks for trying to get things building.  I did run into those
crashes that you're talking about.  (we all have, afaik)  Here's some
things I've tried:

1. modify the optimization level: sometimes this helped, and sometimes
it didn't (inconsistently)
2. reboot haiku: sometimes helps, and sometimes it didn't (inconsistently)
3. run on real hardware vs. emulation: sometimes helps, and sometimes
it didn't (inconsistently)
4. recompile gcc or try different gcc version: seemed to help (I ended
up using a 4.4.2 build from Joe Protsko)

After I got through at least one build of the libjvm.so and friends, I
turned my attention to the "jdk" side.  I put in all the java files
that we had and the C++ files for them, so those are in the
repository.  They may not be in exactly the right place.  I haven't
modified the makefiles at all so that is an outstanding issue.

I switched gears to try to get the java files compiled on haiku.  I
tried to get the latest version of jikes which doesn't have enough
java 5 construct support to help.  I was able to modify some of the
java files to remove the java 5-isms and then compile them with jikes.
 I didn't feel like modifying all of them by hand so I also looked
into some old-ish java 5-ish compilers like the pizza one and another
I forget.

Michael Franz suggested using gcj, so I tried my hand at compiling a
gcc that would work for that purpose.  I tried to compile gcc with
--enable-threads=posix to help out, but the resulting gcj kept
crashing in the garbage collector.  Building gcc is of course no fun,
and I tried to do it "the right way" with bootstrapping, etc., and
that all failed.  I ended up trying this:

LIBS=-lnetwork ../configure --prefix=<prefix>
--enable-languages=c,c++,java --disable-nls --disable-shared
--target=i586-pc-haiku --enable-threads=posix --disable-bootstrap
--disable-libstdcxx-pch

I'd prefer to do the bootstrap because if gcc can't bootstrap, well I
don't have too much confidence in what I just built.  Also I'm not
clear on why the precompiled header stuff doesn't work.

I reported a bug against gcc:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42474 relating to the
linemap_lookup  I didn't spend much time characterizing the behavior,
but I somewhat do believe that this is related to haiku library
loading and initialization.  It may be possible to come up with a
small test case that would exercise the behavior, if that is the case.
 In that case I would guess it has something do with ensuring that the
static variables for a .o are initialized when the .o is loaded into
memory, but this is not really anywhere near my area of expertise.
Looking at the code, it seems difficult to understand how the variable
could not be initialized when you get to linemap_lookup.  (and it
seems like it is unitialized, not just NULL)  This might be related to
signals too, so there's more fun there.

I haven't worked on the "jdk" compilation much for the past few
months.  Last I checked Mike tried to building remote + nfs mounting
but couldn't get the nfs mount to work well enough.  Options I still
haven't checked include using remote + ssh file access on my macbook.
I also wanted to try doing some syntax transforms on the java in the
openjdk to make it jikes compatible.  I downloaded but haven't tried
some of the following:

http://www.program-transformation.org/Stratego/TheDryad
http://www.program-transformation.org/Stratego/JavaFront

I'm something of a purist when it comes to bootstrapping, so I'm
trying to get it all going native.  However, my level of optimism is
declining, so I am approaching the "try to build someplace else".  I
don't have a linux machine handy any longer and the last time I tried
to build on windows I didn't even manage to get the right software.
(compiler version, etc.)  I think that situation (windows) is improved
but I didn't want to spend my effort there.  Aside from the class
files for the shared code, we probably also have to get class files
for some of the haiku specific stuff.  On the positive side, we can
probably build that part native.  So, if anyone is inclined to doing
that, I will try to assist.

Andrew