mlvm failed building coroutine.cpp on Mac OS X 10.4.6
I'm getting warnings building hotspot/src/share/vm/runtime/coroutine.cpp ... the build reports: "cc1plus: warnings being treated as errors" Compiling /Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/runtime/coroutine.cpp rm -f coroutine.o /Users/stephen/dev/java/src/mlvm/sources/ALT_COMPILER_PATH/g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DASSERT -DFASTDEBUG -I. -I../generated/adfiles -I../generated/jvmtifiles -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/asm -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/ci -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/classfile -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/code -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/compiler -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/gc_implementation -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/gc_implementation/g1 -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/gc_implementation/parallelScavenge -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/gc_implementation/parNew -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/gc_implementation/shared -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/gc_interface -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/interpreter -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/libadt -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/memory -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/oops -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/opto -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/prims -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/runtime -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/services -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/utilities -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/cpu/x86/vm -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/os/bsd/vm -I/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/os_cpu/bsd_x86/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"19.0-b03\"" -DHOTSPOT_BUILD_TARGET="\"fastdebug\"" -DHOTSPOT_BUILD_USER="\"stephen\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DJRE_RELEASE_VERSION="\"1.7.0-internal-fastdebug-stephen_2010_11_06_01_32-b00\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -m64 -pipe -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Werror -Wpointer-arith -Wconversion -Wsign-compare -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -c -o coroutine.o /Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/runtime/coroutine.cpp cc1plus: warnings being treated as errors /Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/runtime/coroutine.cpp: In member function 'void CoroutineData::oops_do(Coroutine*, OopClosure*, CodeBlobClosure*)': /Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/runtime/coroutine.cpp:159: warning: NULL used in arithmetic /Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/runtime/coroutine.cpp: In member function 'void CoroutineData::nmethods_do(Coroutine*, CodeBlobClosure*)': /Users/stephen/dev/java/src/mlvm/sources/hotspot/src/share/vm/runtime/coroutine.cpp:203: warning: NULL used in arithmetic make[6]: *** [coroutine.o] Error 1 make[6]: *** Waiting for unfinished jobs make[5]: *** [the_vm] Error 2 make[4]: *** [fastdebug] Error 2 make[3]: *** [generic_build2] Error 2 make[2]: *** [fastdebug] Error 2 make[1]: *** [hotspot-build] Error 2 make: *** [build_product_image] Error 2 ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Auto Reply: mlvm failed building coroutine.cpp on Mac OS X 10.4.6
I'm on vacation from Nov 4 until Nov 15. For ugent issues contact evgeny.yav...@oracle.com ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Few questions about invokeDynamic
Hello, everyone! I couldn't find information about several issues, so I'll ask here for help: I'm using JDK7 b116. When using MethodHandle.invokeExact(...), I can only invoke a method, which signature is "Object (Object[])", anything else fails with: WrongMethodTypeException: ()V cannot be called as ([Ljava/lang/Object;)Ljava/lang/Object; Doing it with invokeVarargs(...) works, but a benchmark showed that it is nearly as slow as good old Java reflection (Method.invoke(...)), which is around 50 times slower than normal method invocation. In contrast, using the language feature "InvokeDynamic.anything();" is just 2.5 times slower than usual method invocation. So my assumption is just that invokeVarargs is slow because of varargs, and invokeExact should be as fast as InvokeDynamic.<...>(...) syntax, but since it fails, I can't know. So my questions are: 1) is that just a bug that invokeExact fails with anything but Object (Object[])? 2) is my assumption correct that normally invokeExact should be as fast as InvokeDynamic.<...>(...)? 3) Is there a tentative timeline about the progress of MLVM in JDK7, or at least when could one expect invokeExact to "work"? Note: I can't use InvokeDynamic.<...>(...) for method-signatures known only at runtime, that's why I need invokeExact. Thank you very much in advance! Best regards, Ivan G S ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Auto Reply: Auto Reply: mlvm failed building coroutine.cpp on Mac OS X 10.4.6
I'm on vacation from Nov 4 until Nov 15. For ugent issues contact evgeny.yav...@oracle.com ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Few questions about invokeDynamic
Le 06/11/2010 11:31, assembling signals a écrit : > Hello, everyone! > > I couldn't find information about several issues, so I'll ask here for help: > > I'm using JDK7 b116. > > When using MethodHandle.invokeExact(...), I can only invoke a method, > which signature is "Object (Object[])", anything else fails with: > WrongMethodTypeException: ()V cannot be called as > ([Ljava/lang/Object;)Ljava/lang/Object; > MethodHandle unlike reflection doesn't require to box arguments in an array. Moreover, invokeExact only works if the method handle's type is the same as the one process by the compiler using the declared type of the parameter. MethodHandle mh = ... (double)mh.invokeExact(3, 2); expects that mh.type is double(int,int). You should use invokeGeneric instead of invokeExact if you want Java conversions. > Doing it with invokeVarargs(...) works, but a benchmark showed that it is > nearly as slow > as good old Java reflection (Method.invoke(...)), which is around 50 times > slower than normal method invocation. > Yes, it's as fast :) > In contrast, using the language feature "InvokeDynamic.anything();" is > just 2.5 times slower > than usual method invocation. So my assumption is just that invokeVarargs is > slow because of varargs, > and invokeExact should be as fast as InvokeDynamic.<...>(...) syntax, but > since it fails, I can't know. > invokedynamic should be faster than MH.invokeExact because invokedynamic don't have to check the type at each invocation but once when you call CallSite.setTarget(). > So my questions are: > 1) is that just a bug that invokeExact fails with anything but Object > (Object[])? > No, invokeExact require to be called with exactly the same signature (bit to bit :) that the signature of the method handle. So if you create a method handle on a static method int foo(int,int), invokeExact must takes two ints and returns an int. (int)mh.invokeExact(2,3) will works. Not that the cast is not a real cast but a hint to the compiler that it will returns an int. > 2) is my assumption correct that normally invokeExact should be as fast as > InvokeDynamic.<...>(...)? > just a little slower. (see below) > 3) Is there a tentative timeline about the progress of MLVM in JDK7, or at > least when could > one expect invokeExact to "work"? > it works :) > Note: I can't use InvokeDynamic.<...>(...) for method-signatures known only > at runtime, > that's why I need invokeExact. > > Thank you very much in advance! > > Best regards, > Ivan G S > Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re[2]: Few questions about invokeDynamic
Remi, thank you a lot for such a quick reply!
I tried to do what you suggested, but it keeps failing.
Note, that I don't use some customized build, but instead, as also mentionen in
previous mail, JDK7 b116.
Could you please try the code by yourself? It's a single class.
Thanks again!
= = = = = = = = = =
CODE
= = = = = = = = = =
import java.dyn.*;
public final class _InvokeDynamic {
private final static MethodHandle methodHandle;
public static int methodA() {
System.out.println("!...@#! MAGIC !...@#!");
return 0;
}
static {
Linkage.registerBootstrapMethod("bootstrap");
methodHandle =
MethodHandles.lookup().findStatic(_InvokeDynamic.class,
"methodA", MethodType.methodType(int.class));
}
private static CallSite bootstrap(Class declaring, String name,
MethodType type) {
System.out.println("declaring class: " + declaring + ", name: "
+ name
+ ", method type:" + type);
CallSite cs = new CallSite();
cs.setTarget(methodHandle);
return cs;
}
public static void main(String[] ars)
throws Throwable {
try {
System.out.println("\n\nATTEMPT 1");
InvokeDynamic.anything();
} catch (Throwable t) {
t.printStackTrace(System.out);
}
try {
System.out.println("\n\nATTEMPT 2");
methodHandle.invokeExact(); // warning: unchecked
generic array creation
} catch (Throwable t) {
t.printStackTrace(System.out);
}
try {
System.out.println("\n\nATTEMPT 3");
(int) methodHandle.invokeExact(); // error: not a
statement
} catch (Throwable t) {
t.printStackTrace(System.out);
}
}
}
= = = = = = = = = =
OUTPUT
= = = = = = = = = =
ATTEMPT 1
declaring class: class _InvokeDynamic, name: anything, method type:()int
!...@#! MAGIC !...@#!
ATTEMPT 2
java.dyn.WrongMethodTypeException: ()I cannot be called as
([Ljava/lang/Object;)Ljava/lang/Object;
at _InvokeDynamic.main(_InvokeDynamic.java:40)
ATTEMPT 3
java.lang.RuntimeException: Uncompilable source code - not a statement
at _InvokeDynamic.main(_InvokeDynamic.java:47)
BUILD SUCCESSFUL (total time: 0 seconds)
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Stack value extractor in Java
I've wanted to write that several times, so before doing something else,
I want to try to convince all VM hackers that they should stop doing
what they currently do and starts to implement a way to export
values from the VM stack into a Java object.
Here is the problem, a lot of unknown and unused languages like Ruby,
Python,
Javascript (and I think also Groovy [1]) aren't typecheckable, at least
under the
following definition.
To be typeckable, for all operations, the following should be true:
rv = op(v1, v2, ... , vi) with v1 ... vi of type T1 ... Ti and rv of type U
rv2 = op(w1, w2, wi) with w1 ... wi of type T1 ... Ti and rv2 of type V
then U == V
This is not true in Ruby because of the way integer overflow are handled.
By example, c = a + b with a and b of type FixNum, c can be a FixNum
or a BigNum depending on the *value* of a and b.
The way to implement that knowing that integer operations rarely overflow
is to generate a bytecode using ints and to escape to the interpreter
if there is an overflow. This trick is by example implemented in nanojit
[2].
But this trick can not be used by JVM languages because there is no
way to get the values stored in the VM stack in order to replay
the operation in the interpreter.
I think we need something like that:
class StackTrace {
public static StackTrace getCurrentStackTrace() { ... }
public int getStackSize() { ... }
public Object getStackValue(int index);
public int getLocalSize() { ... }
public Object getLocalValue(int index);
}
Having this API implemented will really really improve the perf.
Rémi
[1] http://jira.codehaus.org/browse/GROOVY-3991
[2] https://developer.mozilla.org/En/Nanojit
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Few questions about invokeDynamic
Le 06/11/2010 17:36, assembling signals a écrit :
> Remi, thank you a lot for such a quick reply!
>
> I tried to do what you suggested, but it keeps failing.
>
> Note, that I don't use some customized build, but instead, as also mentionen
> in previous mail, JDK7 b116.
> Could you please try the code by yourself? It's a single class.
>
> Thanks again!
>
You've spot a bug:
(int) methodHandle.invokeExact(); // error: not a statement
should compile.
The compiler should consider it as a statement, like it does
for invokedynamic.
If you use a dummy variable, it works:
int foo;
System.out.println("\n\nATTEMPT 1");
foo = (int)InvokeDynamic.anything();
System.out.println("\n\nATTEMPT 2");
foo = (int)methodHandle.invokeExact(); // warning: unchecked
generic array creation
System.out.println("\n\nATTEMPT 3");
foo = (int) methodHandle.invokeExact(); // error: not a statement
Rémi
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [jvm-l] Stack value extractor in Java
On Nov 6, 2010, at 11:38 AM, Rémi Forax wrote:
> I've wanted to write that several times, so before doing something else,
> I want to try to convince all VM hackers that they should stop doing
> what they currently do and starts to implement a way to export
> values from the VM stack into a Java object.
> ...
Yes, JVM languages should be able to do the "deoptimization trick". It works
great for the JVM itself.
Here is a bytecode shape that might make it possible to do so, without the API
you mentioned:
myfn(a,b,c) {
var i,j,k; // init to null if needed
try {
entry point of my fn...
... more stuff ...
... if (bail out #1) throw makeDeopt("cookie #1");
... more stuff ...
... if (bail out #2) throw makeDeopt("cookie #2");
... more stuff ...
return x;
} catch (MyDeopt deopt) {
return executeDeopt(deopt, new Object[]{ a, b, c, i, j, k });
}
}
Here, the cookies passed into the deopts are simple constants. This (probably)
simplifies data movement, since the complicated bundling is done once, at the
catch point. The local variable values could also be bundled up as arguments
to makeDeopt. The throws could be replaced by gotos, but JITs are more likely
to optimize the code the way you want if you use a throw (which the JIT will
probably guess as uncommon).
Would this work for you?
Another problem here is where the executeDeopt guy should go.
Probably you want to fake up some AST interpreter state that expresses the
pending continuations (for enclosing expressions and callers of inlined
functions). Then the AST engine, after it digests the app. some more, can
generate new bytecodes.
Another option would be to generate bytecodes with multiple entry points. This
cannot be directly expressed but could be encoded with a leading pseudo-BCI
parameter, with a switch at the entry point. Again, the above "i,j,k"
structure would be needed. And all the entry points would have to have a
common functional type.
Here's an idea: For each byte-compiled method, compile the normal optimized
version, and also compile a "fallback" version which can be used in corner
cases:
myfn(int bci, args[], locals[]) {
var a=args[0], ...;
var i=locals[0],j,k; // init to null if locals = null
try {
switch (bci) {
case 0:
entry point of my fn...
case 1:
... more stuff ...
... if (bail out #1) throw makeDeopt("cookie #1");
case 2:
... more stuff ...
... if (bail out #2) throw makeDeopt("cookie #2");
case 3:
... more stuff ...
return x;
}
} catch (MyDeopt deopt) {
return executeDeopt(deopt, new Object[]{ a, b, c, i, j, k });
}
}
The fallback could be used for type misses and untaken paths. It could also be
used for continuations (if your language has those). The advantage of a
pre-compiled fallback would be that you would reuse your bytecode compilation
analysis to improve more execution paths, not just the fastest. If that
doesn't matter, a AST-based fallback is perhaps easier to work with.
-- John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
