Simple dynamic language using invokedynamic

[Jochen Theodorou]

Christian Thalinger schrieb:
> Jochen Theodorou wrote:
>> it looks like I am really too stupid for this to build. I manage to 
>> build the openjdk, but the mlvm.... I spend another full day just on 
>> trying getting this run :(
> 
> I try to answer all your questions.

thank you very much!

>> I was too fast the last time, I think I did build the jvm without the 
>> patches. Anyway, the documentation I found and that John linked works so 
>> far, but once the setup is supposedly done, it ends. The documentation 
>> is not for making a build, it is for people writing patches.
>>
>> For example a very simple question... do I need to "make" in ./sources 
>> first or in ./patches. What I did before was running make in patches, 
>> overseeing the error, because it is writing that the build was 
>> successful at the same time, then build in sources and I assume the 
>> changes were not done or overwritten.
> 
> A "make" in patches/make/ should set up the .hg/patches/ links in 
> sources/ to the patches/ forest.  A "hg fstatus" in sources/ should show 
> you, besides the normal JDK forest repositories, the additional patches 
> repositories, e.g.:
> 
> twisti at macbook:~/mlvm/sources$ hg fst
> [.]
> 
> [/Users/twisti/mlvm/patches/hotspot]
> 
> [/Users/twisti/mlvm/patches/jdk]
> 
> [/Users/twisti/mlvm/patches/langtools]
> <snip>

yeah, I see that.

> To see if the patches are applied before you build do e.g.:
> 
> twisti at macbook:~/mlvm/sources/hotspot$ hg qapplied
> meth.patch
> indy.patch

yepp, that's there.

... so make in patches is supposed to do the setup only... because it 
seemed to me that it is doing much more than just that.

>> So I assume the right order is to first run the build in sources and 
>> then in patches... ah well, while trying that I found a few problems, 
>> because I have to set ALT_HOTSPOT_SERVER_PATH and 
>> ALT_HOTSPOT_IMPORT_PATH. But there is no documentation on those and I 
>> gave it really several tries to guess the right once. In the end I maybe 
>> managed, but I am not sure. What are those supposed to be pointing too? 
>> Or is having have to set them a sign that I do something wrong? 
>> Anyway... it is really annoying to have to check several pages of make 
>> output for an error line... isn't there a way to prevent make doing 
>> several jobs at the same time and to let it stop at the error then? I 
>> always thought one make job at the same time is default anyway...
> 
> The only thing you have to set to build a JSR 292 capable JDK is (IIRC, 
> as I set ALT_SLASH_JAVA):
> 
> ALT_BOOTDIR

well, for the jdk build I set ALT_BOOTDIR, ALT_BINARY_PLUGS_PATH, 
ALT_JIBX_LIBS_PATH. And then working the JVM works well in sources. but 
that was no problem, since the build instructions for the jdk work 
perfectly fine.

[...]
> A "make help" in sources/ gives you a list of targets and one of the 
> targets is:
> 
> debug_build

thanks... but this seems to say, that all the patches got applied. And 
then that means that for me the mlvm is not working at all. Even simple 
things won't do.

strange... all of a sudden I get a compilation error:

> /home/blackdrag/coding/davinci/mlvm/sources/hotspot/src/cpu/x86/vm/methodHandles_x86.cpp: In function 'void trace_method_handle_stub(const char*, oopDesc*, intptr_t*, intptr_t*)':
> /home/blackdrag/coding/davinci/mlvm/sources/hotspot/src/cpu/x86/vm/methodHandles_x86.cpp:276: error: format '%016lx' expects type 'long unsigned int', but argument 3 has type 'oopDesc*'
> /home/blackdrag/coding/davinci/mlvm/sources/hotspot/src/cpu/x86/vm/methodHandles_x86.cpp:276: error: format '%016lx' expects type 'long unsigned int', but argument 4 has type 'intptr_t*'
> make[7]: *** [methodHandles_x86.o] Error 1


bye Jochen

-- 
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/