Hi all,
looks like I finally managed to join this list too. And I already have a
request to those making the adminitrative part here.. Is it possible to
let the mailing list server set a reply-to for the list? That would make
things a bit more easy.
bye blackdrag
--
Jochen blackdrag
John Rose schrieb:
Glad you're here, blackdrag!
OK, let's try the reply-to-list setting (as of this message).
If anyone has further thoughts on this, please mail me directly.
looks fine now
bye Jochen
--
Jochen blackdrag Theodorou
The Groovy Project Tech Lead
Hi all,
from some messages to this list I get that the invokedynamic patch will
now probably work against openjdk7 b42. Since I was able to build that
version here on my computer I would be again interested in testing it
for Groovy. But for this I would need again an explanation of how to get
Rémi Forax schrieb:
Jochen Theodorou a écrit :
John Rose schrieb:
If you pull and build again, you can stop using -Xint. (I hope. :-)
John,would it be a problem to make a page on the mlvm project page
explaining exactly how to build mlvm and in what environments it maybe
won't
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
Christian Thalinger schrieb:
[...]
diff --git a/src/cpu/x86/vm/methodHandles_x86.cpp
b/src/cpu/x86/vm/methodHandles_x86.cpp
--- a/src/cpu/x86/vm/methodHandles_x86.cpp
+++ b/src/cpu/x86/vm/methodHandles_x86.cpp
@@ -273,7 +273,7 @@ void trace_method_handle_stub(const char
Christian Thalinger schrieb:
[...]
Currently only 32-bit x86 works, no 64-bit support yet. We decided to
use x86_32 as our main development architecture and port stuff to the
other architectures later, when it's proven to work.
looks like I am supposed to run that VM with 32bit libs too...
Chanwit Kaewkasi schrieb:
Using the debug build and base_hsdis, the code seems to be more
understandable to me.
For the Fibonacci program, inlining is working great. Numerical
runtime methods, i.e. plus and minus, has been inlined into a compiled
method of Fib.fib.
However, a lot of
Christian Thalinger schrieb:
Christian Thalinger wrote:
Guillaume Laforge wrote:
On Tue, Jul 14, 2009 at 12:19, Christian
Thalingerchristian.thalin...@sun.com wrote:
Jochen Theodorou wrote:
show if it is worth the effort. Well.. cannot use invokedynamic on my
machine yet...
Why
hi all,
I am in urgend need of an actual VM with MethodHandles, but this is as
always quuite complicated. This time I created a chroot envrionment for
32 bit, that was where I last time had to stop. I managed to get it
compiled by the patch that was provided here 5 months ago and finally
had
Rémi Forax schrieb:
Le 09/09/2009 20:42, Jochen Theodorou a écrit :
hi all,
I am in urgend need of an actual VM with MethodHandles, but this is as
always quuite complicated. This time I created a chroot envrionment for
32 bit, that was where I last time had to stop. I managed to get
Jochen Theodorou schrieb:
Rémi Forax schrieb:
Le 09/09/2009 20:42, Jochen Theodorou a écrit :
hi all,
I am in urgend need of an actual VM with MethodHandles, but this is as
always quuite complicated. This time I created a chroot envrionment for
32 bit, that was where I last time had to stop
Rémi Forax schrieb:
[...]
and
java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic FidgetDemo
java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic FidgetDemo
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error
Christian Thalinger schrieb:
[...]
I think that was a bug we had once. Is your mlvm repository up-to-date?
from the same day, so I would say: yes.
Btw. if the interpreter is fast enough for you, you can now build a
64-bit VM. I've pushed the changes a few days ago.
no, the interpreter is
Rémi Forax schrieb:
Le 11/09/2009 03:08, Jochen Theodorou a écrit :
Charles Oliver Nutter schrieb:
You could certainly use the interpreter to start prototyping whatever
you are working on. I used interpreted mode for much of the JRuby
invokedynamic work.
well I wanted to run
Lukas Stadler schrieb:
Hi everybody!
I've just checked in the first prototype of a coroutine implementation.
It's implemented using the continuations framework, so it's not very
speedy (~1µs per context switch in a simple example) but it allows me to
experiment on how the API for
Dalibor Topic wrote:
Via puredanger's twitter stream comes
http://www.regonline.com/Checkin.asp?EventId=859228
No reaction to this yet. The registration page has a link for the 2010
summit, but it points still to the 2009 version.
bye Jochen
--
Jochen blackdrag Theodorou
The Groovy Project
Am 15.02.2011 15:50, schrieb Kirill Shirokov:
Hi All,
Oracle will make an one-day conference called Java Tech Day in St.
Petersburg, Russia. There will be a section called ask the experts for
a number of JDK7 features including JSR 292. I'm asked to be a live
emulator of JSR292 expert there.
Am 15.03.2011 23:41, schrieb Rémi Forax:
[...]
If the callsite is inlined, won't
that mean that then we have those types hard referenced as well and that
I cannot do anything against that?
A callsite can be inlined more than once.
So the reference to the mh can not be dropt
I ask because I
Am 16.03.2011 20:06, schrieb Charles Oliver Nutter:
On Wed, Mar 16, 2011 at 3:36 AM, Jochen Theodoroublackd...@gmx.org wrote:
The result, should I have understood correctly, will be, that each
scriptn will cause the former scriptn (lastScript) to be referenced in a
way that prefents that from
Am 26.05.2011 11:03, schrieb Christian Thalinger:
[...]
I looked at the inlining tree of fib and everything looks good and is
inlined. There is one invokeExact which is:
@ 43 java.lang.invoke.MethodHandle::invokeExact (42 bytes) too
big
but bumping the MaxInlineSize just shows that
Am 09.07.2011 10:48, schrieb Hiroshi Nakamura:
Hello,
I heard that jsr292 makes dynamic method lookupinvocation faster than
reflection so I did some performance comparison against plain
reflection. I'm sending this mail since the result looks strange to
me.
Code is here:
Am 29.11.2011 23:34, schrieb Thomas Wuerthinger:
On 11/29/11 11:22 PM, Jochen Theodorou wrote:
Am 29.11.2011 22:32, schrieb Mark Roos:
[...]
I just finished a paper (link below) on JVM startup time which states
that for small programs its around
70ms. So I assume there is some other startup
Am 30.11.2011 14:02, schrieb Rémi Forax:
[...]
What kind of initialization work is this? Could the result of that work
be cached?
we have to setup the initial meta class system, which requires to use
reflection to inspect some classes and other work. Yes, this could be
cached, if we would
Am 01.12.2011 00:35, schrieb Rémi Forax:
[...]
The only way I see to avoid that is to not load the meta-class
until someone reference them so you can compile this example
to System.out.println(2) and if there is a ref to a meta-class somewhere,
discard the code and recompile it with meta-class
Hi all,
I noticed some of the error message are a bit strange. For example I was
going to use bindTo for a boolean, but primitives are not allowed. The
error message I then get is:
no leading reference parameter
Which makes no sense at all. Looking at the code:
if
Am 06.01.2012 17:22, schrieb John Rose:
On Jan 6, 2012, at 4:57 AM, Jochen Theodorou wrote:
I see where it comes from, but reusing that instead of making a new if
is not really needed, is it?
Do people here agree this should be improved?
The javadoc for this throw is:
* @throws
Hi all,
after some modifications to my code I suddenly got this exception:
java.lang.InternalError: JVM cannot find invoker for
(CompilationUnit,TreeNodeBuildingNodeOperation,int)Object
at java.lang.invoke.Invokers.lookupInvoker(Invokers.java:91)
at
Am 31.01.2012 23:20, schrieb Jochen Theodorou:
Hi all,
after some modifications to my code I suddenly got this exception:
java.lang.InternalError: JVM cannot find invoker for
(CompilationUnit,TreeNodeBuildingNodeOperation,int)Object
at java.lang.invoke.Invokers.lookupInvoker(Invokers.java:91
Am 02.02.2012 14:37, schrieb Christian Thalinger:
On Feb 2, 2012, at 2:34 PM, Jochen Theodorou wrote:
Am 02.02.2012 12:21, schrieb Jochen Theodorou:
Am 01.02.2012 12:38, schrieb Rémi Forax:
[...]
This is weird,
All tests but one in UberTestCaseJavaSourceGroovyPackagesSecurity pass
for me
Am 02.02.2012 19:40, schrieb Jochen Theodorou:
[...]
Every help is very much appreciated.
On further investigation the error seems really to be related to one of
the parameters being an instance of a class with a private modifier set.
The key point in that is maybe that the class
Am 02.02.2012 21:02, schrieb Jochen Theodorou:
Am 02.02.2012 19:40, schrieb Jochen Theodorou:
[...]
Every help is very much appreciated.
On further investigation the error seems really to be related to one of
the parameters being an instance of a class with a private modifier set.
The key
Am 07.02.2012 17:29, schrieb Jim Laskey:
MethodType type = MethodType.methodType(Constructor.class,
Class[].class);
MethodHandle mh = MethodHandles.lookup().findVirtual(Class.class,
getDeclaredConstructor, type);
MethodType target =
);
mh.invokeExact((Object)Class.class, (Object[])new Class[0]);
Cheers,
-- Jim
On 2012-02-07, at 12:37 PM, Jochen Theodorou wrote:
Am 07.02.2012 17:29, schrieb Jim Laskey:
MethodType type = MethodType.methodType(Constructor.class,
Class[].class);
MethodHandle mh
Am 07.02.2012 18:29, schrieb Jim Laskey:
Worked okay for me. So must be addressed in a later release. :-/
later than jdk7u2? oh boy. I would feel better if I could find a bug
report that shows the problem and that is resolved. Then I would at
least have something for the release notes. But I
Hi all,
I have the feeling we have talked about this already, but I couldn't
really find it and back then it was independend of invokedynamic...
Anyway...
Assuming I have an interface Foo with a void method foo(). And assuming
I have the class Bar0, Bar1 to BarN implementing that interface.
Hi all,
I wanted to ask you of your opinion. If I am going to compile something
like a+b-c and a,b,c are all primtives, but I won't know that the
results will be really the primtives too, then this means I will most
probably compile it like this:
invokedynamic(minus, invokedynamic(plus,a,b),
Am 13.05.2012 19:21, schrieb Charles Oliver Nutter:
[...]
You could also encode a+b-c as a single invokedynamic operation, but
I guess you're looking for a general solution...
yes, I am looking for a general solution. I was thinking of making the
whole expression as a MethodHandle combination,
Am 13.05.2012 19:55, schrieb Rémi Forax:
[...]
I think currently Groovy allows to replace + by a method
that will return everything you want.
But here, I think the spec of Groovy (if it means something)
should be changed to say that when your replace a method
by another, the return type must
Am 14.05.2012 08:55, schrieb Rémi Forax:
[...]
so you mean to tell me that I have first to convert the Object to an
Integer and that Integer to int, instead of directly converting the
Object to an int? I see, I will try that out.
Yes.
You should not have to do that because you first check if
Am 14.05.2012 17:19, schrieb Charles Oliver Nutter:
On Mon, May 14, 2012 at 4:32 AM, Jochen Theodoroublackd...@gmx.org wrote:
That it is slower at first is ok. Only I kind of assumed, that such
things can be optimized away. The less the JIT can optimize, the more I
have to do that and work
Am 21.05.2012 07:34, schrieb Mark Roos:
Hi Jochen
I ran into a similar issue ( between versions within jdk8 ) where the
default compile
mode had changed to tieredCompile. This made the benchmark timing
inconsistent.
I have learned to look closely at the defaults and have moved to
Am 21.05.2012 20:18, schrieb Mark Roos:
Hi Jochen
Since I am using a Mac I can get a wide range of builds to try (almost
daily)
http://code.google.com/p/openjdk-osx-build/
For the compiler Christian recommended I try
-XX:-TieredCompilation
which was my problem on jdk8 versions
ok, I
no one helping me on the assembly analysis?
Am 19.05.2012 09:23, schrieb Jochen Theodorou:
Hi all,
I was about to get a brand new assembly to ask some questions on the
list here when I installed the newest available jdk7 update 6. I ran my
simple Fibonacci test program and noticed
Am 24.05.2012 13:43, schrieb Rémi Forax:
[...]
if invokedynamic knows more, you can provide a path with
less boxing so it's usually better.
I changed Groovy to get rid of getCallSiteArray and added
backpropagation of the return type to the next directly involved method
call. So in
int
Hi all,
I was wondering... if I have code like this:
list.each { x - foo(x) }
list.each { x - bar(x) }
list.each { x - something(x) }
then isn't it the a case where within the each method we easily get
something megamorphic, since there are too many different kinds of
lambdas involved? Isn't
Am 21.06.2012 13:57, schrieb Krystal Mok:
That's the inlining problem that Cliff Click was talking about [1], right?
yes, the issue was actually mentioned more than once on this list already
I wonder how well the new interpreter design in Graal would handle this
kind of case, since it's
Am 21.06.2012 13:21, schrieb MacGregor, Duncan (GE Energy):
Yes, it is very easy for those sites to become megamorphic. We work round
this by using exactInvokers on function invocation call sites, and caching
on the method type of the functions rather than the types.
So in my own words... you
Am 21.06.2012 16:00, schrieb Rémi Forax:
On 06/21/2012 03:52 PM, Jochen Theodorou wrote:
Am 21.06.2012 13:57, schrieb Krystal Mok:
[...]
I wonder how well the new interpreter design in Graal would handle this
kind of case, since it's supposed to have picked the good parts from
trace-based
Am 21.06.2012 15:55, schrieb Jochen Theodorou:
Am 21.06.2012 13:21, schrieb MacGregor, Duncan (GE Energy):
Yes, it is very easy for those sites to become megamorphic. We work round
this by using exactInvokers on function invocation call sites, and caching
on the method type of the functions
Am 21.06.2012 15:58, schrieb Rémi Forax:
[...]
I spend a couple of days in Linz last month with the Autrian part of the
Graal team (Thomas, Lukas and Gilles)
and we discuss about this issue (among other things).
I think we should book a room during the Summit to try to see if
something can be
Hi all,
just to be sure I understand correctly... afaik there are two things
invokedynamic cannot do.
(1) calling private methods
actually I am not sure this is really true. There is a Lookup instance I
can use to get handles to private methods (afaik), therefore it should
be possible. Or is
Am 26.06.2012 11:59, schrieb Rémi Forax:
On 06/26/2012 11:40 AM, Jochen Theodorou wrote:
Hi all,
just to be sure I understand correctly... afaik there are two things
invokedynamic cannot do.
(1) calling private methods
actually I am not sure this is really true. There is a Lookup instance
Am 26.06.2012 13:06, schrieb Rémi Forax:
[...]
(2) calling super()
afaik I cannot generate a call site that replaces the invokeSpecial call
to a super class constructor.
You can call super.foo()
ah true... this is not reflection.. even if I get the handle from the
super class it won't call
Hi all,
assuming you have to compile code with indy that realizes this:
Class.forName(x)
Meaning, we want to execute forName from Class using invokedynamic. If
you then have frames in your trace looking like this:
java.lang.Class.forName0(Native Method)
Am 10.07.2012 22:56, schrieb Rémi Forax:
[...]
Class.forName(name) is equivalent to Class.forName(name, true,
lookup.lookupClass().getClassLoader())
As true and lookup.lookupClass().getClassLoader() are constant in the BSM,
you can bound them using insertArguments.
also an interesting idea,
Am 27.07.2012 18:44, schrieb Rémi Forax:
As traditionally for the JVM Summit,
I'm please to announce a new version of the JSR 292 backport,
http://code.google.com/p/jvm-language-runtime/downloads/list
This version as some speed improvements and numerous bug fixes thanks to
the Nashorn Team.
Am 29.10.2012 17:03, schrieb Christian Thalinger:
[...]
...or move to JDK 8 until 7u with an updated 292 is released. Doesn't
the NoClassDefFoundError bite you anyway?
you want me earnestly to tell the Groovy users that invokedynamic on
JDK7 is useless ;) It is difficult enough to let people
Am 29.10.2012 17:29, schrieb Remi Forax:
[...]
In my opinion, the best is to use Unsafe.ensureClassInitialized() the
first time you call the BSM, it should be enough.
That one I did not know so far, interesting. My current work around is
to go with the fallback internal old MOP path... which
Am 29.10.2012 22:13, schrieb Christian Thalinger:
[...]
What version of Groovy uses JSR 292?
starting Groovy 2.0 you can enable invokedynamic. Though I use it only
for method calls there and the implementation has still many quirks.
Soon we will release Groovy 2.1, in which invokedynamic will
Hi John,
Am 16.11.2012 04:09, schrieb John Rose:
On Nov 15, 2012, at 3:32 PM, John Rose wrote:
It can be right, but only if the actual argument is a null reference.
If it is a non-null Byte, it must unbox to a byte and then widen to a
float.
Well, actually, in this case, the NPE should
Am 16.11.2012 00:32, schrieb John Rose:
[...]
What you are seeing is a bug. I can reproduce this in JDK 7 but not in
JDK 8. The upcoming JDK 7 update will fix this, since it is a backport
from 8.
ah, finally the backport of jdk8 ;) I hope it does not break other
things;) Btw, I noticed this
Hi all,
in another thread I was already explaining, that I do need for a certain
method call the initialized class, to select the right method. Remi for
example then adviced me to use Unsafe and the method
ensureClassInitialized... well after adding that I get a nice hs_err log
file with
Am 16.11.2012 16:05, schrieb Remi Forax:
Jochen,
can you extract a simple test class that reproduce the bug ?
Also, methods of sun.misc.Unsafe are not protected again send null as
arguments,
so you have to do the check before calling unsafe.XXX.
I am sure it is not null... as for a
Am 16.11.2012 20:43, schrieb Jochen Theodorou:
Am 16.11.2012 17:31, schrieb Remi Forax:
[...]
clinit is called the first time you call a constructor, a static
method or get/set the value of a static field.
Remi I am aware of that, but I cannot simply call a static method, or
create
/szegedi/dynalink/blob/master/src/main/java/org/dynalang/dynalink/DynamicLinkerFactory.java#L169
[2]
https://github.com/szegedi/dynalink/blob/master/src/main/java/org/dynalang/dynalink/linker/LinkRequest.java#L59
On Thu, Dec 20, 2012 at 2:10 PM, Jochen Theodorou blackd...@gmx.org
mailto:blackd
Am 20.12.2012 22:35, schrieb Mark Roos:
[...]
I see the same for my Smalltalk implementation. In looking at my
problem it seems that the
megamorphic problem is temporal. In other words over a short time
period the site is monomorphic
then becomes megamorphic as more code runs.
yes, that
Hi Remi,
yes, I remember the discussion you had with John. I was there too ;)
Am 21.12.2012 00:32, schrieb Remi Forax:
On 12/20/2012 11:44 PM, Jochen Theodorou wrote:
Am 20.12.2012 22:35, schrieb Mark Roos:
[...]
[...]
Another thought I had was to determine if a method has megamorphic
Am 21.12.2012 06:03, schrieb Charles Oliver Nutter:
On Thu, Dec 20, 2012 at 7:10 AM, Jochen Theodorou blackd...@gmx.org wrote:
let us assume the following example... I have a method foo
public Object foo(Object arg){return bar(arg)}
nothing fancy, quite simple... and let us assume foo
Am 21.12.2012 12:28, schrieb MacGregor, Duncan (GE Energy Management):
I've been thinking about this due to the extensive mixin hierarchy in our
runtime presenting some potential problems with the number of types being
seen by some areas of code in some applications. It's going to be hard to
To drive the language list down there further I name the Groovy
variant... fully aware that it is not likely something for Java at all.
In Groovy we do:
class Egg {
int color
}
This will generate a getColor and a setColor method, just like you
expect from the Java Bean Spec. You can still
Hi all,
I just noticed something interesting. I had a small program that
constantly failed with the famous NoClassDefFoundError, that is still
such an major annoyance, even in jdk7u11. I tried out jdk8b78 and the
program failed to start as well. But this time because I tried to lookup
a
Am 25.01.2013 22:51, schrieb John Rose:
On Jan 25, 2013, at 7:04 AM, Jochen Theodorou wrote:
I just noticed something interesting. I had a small program that
constantly failed with the famous NoClassDefFoundError, that is still
such an major annoyance, even in jdk7u11. I tried out jdk8b78
I would be very interested in reading that
Am 19.02.2013 14:37, schrieb Eric Bodden:
Hi all.
Kamil Erhard, a student of mine, and myself have prepared a paper
draft on a novel framework for invokedynamic dispatch that we call
DynaMate. The framework is meant to aid language developers in
Hi all,
assuming I have in Java a method:
public static Object invoke(MethodHandle mh, Object[] args) {
try {
return mv.invokeWithArguments(args);
} catch (Throwable th) {
ExceptionUtils.sneakyThrow(th);
}
}
(sneakyThrow is to work around checked exceptions and does basically
Am 21.03.2013 20:49, schrieb Remi Forax:
[...]
I suppose you take a look to the instances.
You can do something similar actually by using invokedynamic +
a guardWithTest that checks already seen instances instead of doing a
plain mh.invoke*
I think Duncan and Georges do something like that in
Am 21.03.2013 20:31, schrieb Krystal Mo:
Hi Jochen,
At least with the current tip version of HotSpot, the
mh.invokeWithArguments() callsite is not likely to get its actual target
inlined into the caller; we depended a lot on being able to prove that
the MethodHandle is a (JIT-)compiled-time
Am 22.03.2013 10:11, schrieb Remi Forax:
[...]
I don't think it's a good idea to expose directly method handles to users,
it's better to encapsulate it into a Groovy object corresponding to a
function or a closure so you can add a bunch of invoke overloads.
what invoke overloads are you
Am 22.03.2013 10:35, schrieb Remi Forax:
On 03/22/2013 10:24 AM, Jochen Theodorou wrote:
Am 22.03.2013 10:11, schrieb Remi Forax:
[...]
I don't think it's a good idea to expose directly method handles to users,
it's better to encapsulate it into a Groovy object corresponding to a
function
Hi all,
basically ClassValue is there so that my runtime/framework or whatever
can store information and bind it to a class. The information is then
available as long as the class exists. In Groovy3 I am going to use this
for meta classes.
Some time ago a user came up with a special need, he
[...]
Could you describe in some
more detail, what are meta classes in groovy runtime in terms of how
they are generated (lazily at runtime or ahead of runtime?), what
dependencies they can have and who is dependent on them. I assume they
are generated at runtime, since if they were
Am 27.04.2013 23:26, schrieb John Rose:
...
Each instance of the Groovy runtime will use a distinct ClassValue instance.
If the ClassValue instance goes dead, then all the values (for each
class) bound using that instance should go dead also.
If they don't it's a bug.
well... I assume that
sorry for answering so late...
Am 27.04.2013 23:54, schrieb John Rose:
[...]
As a simple example: Make a ClassValue object, bind a 1Mb array to
Object.class using it, and then throw it all away. (Except
Object.class, naturally.) Even if you do this in a loop, you should not
get a storage
Hi,
I am currently investigating here some performance issues and I may have
found a culprint here - invokeExact. My case is one where method caching
fails and I will have to do an invokeExact from Java - meaning without
the invokedynamic bytecode and with a non constant method handle. I am
Am 07.05.2013 17:42, schrieb MacGregor, Duncan (GE Energy Management):
Which version of the jvm are you seeing this problem on, and are you
adapting the method handle every time as well as exact invoking it?
the version is a 1.8.0-ea. Since this is a generic way of method
invocation I have to
please forget what I wrote... I made a mistake
Am 08.05.2013 11:59, schrieb Jochen Theodorou:
Am 07.05.2013 17:42, schrieb MacGregor, Duncan (GE Energy Management):
Which version of the jvm are you seeing this problem on, and are you
adapting the method handle every time as well as exact
Am 07.05.2013 19:31, schrieb Christian Thalinger:
[...]
Do you have any numbers?The problem is that if the MH is not constant
we can't do any inlining and it will be an out-of-line call (with a
trampoline in between). Is
your DMH a static or virtual?
arg... looks like I made a mistake. It
Am 08.05.2013 23:12, schrieb John Rose:
On May 8, 2013, at 5:33 AM, Jochen Theodorou blackd...@gmx.org wrote:
Am 07.05.2013 19:31, schrieb Christian Thalinger:
[...]
Do you have any numbers?The problem is that if the MH is not constant
we can't do any inlining and it will be an out-of-line
Am 10.05.2013 02:40, schrieb Christian Thalinger:
[...]
That's because your method handle is not constant and so the compiler cannot
inline the call.
And you tell me that in the first case the call was inlined? That is
unexpected. And if that is the case, then why does this:
Am 10.05.2013 02:40, schrieb Christian Thalinger:
[...]
That's because your method handle is not constant and so the compiler cannot
inline the call.
If I change the test to (using 1.8.0):
Object[] os = {str, 1, new ArrayList(), new Object()};
MethodType invokeType =
Hi all,
The Oracle JDK internal method sun.reflect.Reflection.
getCallerClass(int) is planned to be disabled in Oracle JDK 7u40. It is
considered for removal in a later 7 update release.
As you may be aware, the Oracle JDK internal
sun.reflect.Reflection.getCallerClass(int) method has been
Am 02.07.2013 15:10, schrieb Attila Szegedi:
FWIW, I'm currently working on Dynalink correctly supporting methods
that are marked with @CallerSensitive; My tests from Nashorn show
things work as expected, i.e. you can give some permissions to your
script based on its URL in the security
Am 02.07.2013 15:10, schrieb Alessio Stalla:
On Tue, Jul 2, 2013 at 2:56 PM, Jochen Theodorou blackd...@gmx.org wrote:
I imagine other languages will have similar problems here and there...
or not?
Hmm... what are you using that method for? I'm not aware of uses of it
in ABCL, but that may
Am 03.07.2013 10:50, schrieb Jochen Theodorou:
[...]
But with the new logic I see no other way, then to throw an exception
and walk the trace.
addendum:
Somehow I thought the trace has classes... it does not. With only
Strings I can do exactly nothing, since I need the loader and by String
I
Hi all,
5 days nothing... Does that mean it is like that, there is no way around
and I have to explain my users, that Java7/8 is going to break some
minor functionality?
bye blackdrag
--
Jochen blackdrag Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german
Am 10.07.2013 10:40, schrieb Noctarius:
[...]
Maybe a solution could be an annotation to mark calls to not
appear in any stacktrace?
I had that idea too, and then found it no solution... only I don't
remember why anymore.. Didn't JSR292 include at one time such an annotation?
bye Jochen
--
Am 11.07.2013 06:09, schrieb Charles Oliver Nutter:
[...]
In JRuby, we pass the calling object into every call site to check
Ruby-style visibility at lookup time (we can't statically determine
visibility, and we do honor it). That gets you a bit closer to being
able to get the caller's
Am 30.07.2013 14:17, schrieb Peter Levart:
[...]
So what would give Groovy or other language runtimes headaches when all
there was was a parameter-less getCallerClass() API? Aren't the
intermediate frames inserted by those runtimes controlled by the
runtimes? Couldn't the surface
Am 30.07.2013 14:17, schrieb Peter Levart:
[...]
So what would give Groovy or other language runtimes headaches when all
there was was a parameter-less getCallerClass() API? Aren't the
intermediate frames inserted by those runtimes controlled by the
runtimes? Couldn't the surface
Am 30.07.2013 16:16, schrieb Peter Levart:
On 07/30/2013 03:19 PM, Jochen Theodorou wrote:
Am 30.07.2013 14:17, schrieb Peter Levart:
[...]
So what would give Groovy or other language runtimes headaches when all
there was was a parameter-less getCallerClass() API? Aren't the
intermediate
1 - 100 of 187 matches
Mail list logo
