On Jul 17, 2012, at 4:04 PM, Christian Thalinger wrote:
>>
>> I see in several files next code pattern. Should we call
>> throw_IncompatibleClassChangeError() as we do in other places?:
>>
>> + if (!EnableInvokeDynamic) {
>> +// rewriter does not generate this bytecode
>> +__ should_no
Changeset: 88f29874d717
Author:twisti
Date: 2012-07-18 18:57 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/88f29874d717
rebase to current hsx/hotspot-comp
! meth-lazy-7023639.patch
! meth-lazy-7023639.review.patch
! series
Changeset: 65906046e5fd
Author:twisti
Date: 2012-07-18 17:11 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/65906046e5fd
meth-lazy: update for review comments
! meth-lazy-7023639.review.patch
___
mlvm-dev mailing list
mlvm-d
On Jul 17, 2012, at 4:32 PM, Vladimir Kozlov wrote:
> >> linkResolver.cpp:
> >> Can you replace infinite for(;;) in resolve_invokedynamic() with finite
> >> loop since the body is executed once or twice.
> >
> > Hmm. What limit do you have in mind?
>
> It is not loop by logic. The code is tryi
FWIW
Everything RTALK works on Stephen's 7/11/2012 build. Thank you Stephen.
While generally faster than 7u2 I do have a strangeness in that when my
target is a chain of methodHandles its much slower then when my target
is a methodHandle-callsite-chain of handles. My second case is where I
ad
(sorry for not replying to original message, just subscribed)
This feels outright wrong:
+static Map CACHE = new IdentityHashMap<>();
+
+static Data get(String types) {
+final String key = types.intern();
+Data d = CACHE.get(key);
+if (d == null
