On 2015-01-14 08:22, David Holmes wrote:
Hi Roman,
On 14/01/2015 7:41 AM, Roman Kennke wrote:
Ok I think I found a way to avoid copying the whole #define block just
for one line. I define that line before (and empty in case of SHARK) and
use that inside the big #define.
http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/webrev.02/
Can you use SHARK_ONLY or NOT_SHARK macros? I think that would be
cleaner.
Still need a second hotspot reviewer - preferably someone from
compiler team.
And was a bug filed for this?
A bug was filed at least: https://bugs.openjdk.java.net/browse/JDK-8068598
I promised to handle the push when it's all reviewed.
/Erik
Thanks,
David
Please review and push if ok.
Roman
Am Freitag, den 09.01.2015 um 15:27 +1000 schrieb David Holmes:
Hi Roman,
Commenting on the hotspot changes ...
On 8/01/2015 9:01 PM, Roman Kennke wrote:
Hi Erik,
I'm CC-ing hotspot-dev for review of Hotspot code related changes.
Yes, some additional changes to Hotspot are required. This is the full
set of changes needed to build and run Shark:
http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/webrev.01/
In detail:
- In the Makefile fix a typo to be able to build unzipped debuginfo.
Ok.
- In ciTypeFlow.cpp only include some files and code only when
building
C2. I don't think that code makes sense outside of C2. (That's the
issue
that you've seen).
Looks okay but someone from compiler team needs to comment. There
may be
other code that need adjusting.
- In systemDictionary.cpp, exclude some code for Shark that creates
and
checks native wrappers for method handle intrinsics. Invokedynamic
stuff
is not yet implemented in Shark, so we can't do this.
Ok.
- In allocation.hpp, exclude the operator overrides for new etc, LLVM
does allocations itself, and this would blow up.
I'm intrigued as the allocation strategy is not tied to the compiler
but
pervasive to the whole VM runtime.
- In handles.hpp and handles.inline.hpp, I added an argument
check_in_stack so that I can disable the in-stack check for the
SharkNativeWrapper. The SharkNativeWrapper is allocated on-heap and
the
methodHandle inside the SharkNativeWrapper. I could have excluded that
check altogther using an #ifndef SHARK, but the way I implemented it
seemed more finegrained.
I'd prefer an ifndef SHARK rather than change the API.
Thanks,
David
- In SharkCompiler, I pulled out the code to initialize LLVM into its
own method, and the call to set_state(initialized) out of the
execution-engine-lock. This would otherwise complain about wrong
lock-ordering.
- In SharkRuntime, I changed the cast from intptr_t to oop to work
with
the new picky compilers ;-)
Please review.
Thanks and best regards,
Roman
Am Donnerstag, den 08.01.2015 um 11:03 +0100 schrieb Erik Joelsson:
Hello Roman,
This addition looks good to me.
Thinking about what the others said, it might be inconvenient to have
all this be pushed to different forests. I tried applying all the
changes to jdk9/hs-rt, but I can't seem to build zeroshark.. Did you
have more hotspot changes to be able to finish the build?
My failure is:
ciTypeFlow.o
/localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp
In file included from
/localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/regmask.hpp:29:0,
from
/localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/compile.hpp:40,
from
/localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp:38:
/localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/optoreg.hpp:40:39:
fatal error: adfiles/adGlobals_zero.hpp: No such file or directory
From what I can see, adfiles are not generated for zero or
zeroshark
builds, so the include should probably be removed.
Would you still like me to push what you currently have to hs-rt?
/Erik
On 2015-01-07 21:21, Roman Kennke wrote:
Hi Erik,
When I built Zero and Shark on my Raspberry Pi, I noticed another
problem when copying jvm.cfg into the right places. I fixed it in a
similar way as I did for the SA stuff:
http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.02/
I think that should be all for now.
Please push that into JDK9 if you think that's fine.
Best regards,
Roman
Am Mittwoch, den 07.01.2015 um 17:49 +0100 schrieb Erik Joelsson:
On 2015-01-07 17:29, Roman Kennke wrote:
Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
On 2015-01-07 17:11, Roman Kennke wrote:
Hi Erik,
Do you have a bug for this?
No.
I haven't pushed any changes to JDK in a while. Is it
possible in the
meantime for me to create my own bugs? Otherwise, please file
one for
me :-)
You should be able to log in to https://bugs.openjdk.java.net
and create
bugs since you have an OpenJDK identity.
Done:
https://bugs.openjdk.java.net/browse/JDK-8068598
While I'm at it, is it possible for me to push my own changes
(except
hotspot of course)? If yes, what needs to be done for
regenerating the
configure files? Simply run autogen.sh in common/autoconf with
whatever
version of autotools I have? Or doesn't it make sense at all
b/c you
need to regenerate your closed scripts?
It requires you to run common/autogen.sh yes, and that will
require you
to have autoconf 2.69 installed. But since we also need to
regenerate
the closed version, I can take care of the push for you. Will do it
tomorrow if that's ok?
/Erik
Roman