nal interface
return sam.bindTo(lambda);
}
Best regards,
Vladimir Ivanov
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
https://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
() called from ClassFileParser::parse_fields()).
vmholder is an object field injected into ResolvedMethodName class. It's
an ordinary object field, so there's no additional GC support needed to
support it.
Best regards,
Vladimir Ivanov
Thanks
- Ioi
On 5/7/18 5:45 PM, Vladimir Ivanov wrote:
Ioi
Ioi,
Though the field is never accessed directly,
ResolvedMethodName::vmholder is still tracked by GC and keeps the
metadata it accompanies (RMN::vmtarget) alive until RMN is reachable.
Best regards,
Vladimir Ivanov
On 5/7/18 17:29, Ioi Lam wrote:
I don't see anywhere in HotSpot that uses
).
Best regards,
Vladimir Ivanov
[1] new RubyClass(Ruby.this) in
public static class Ruby {
private ClassValue cache = new ClassValue() {
protected RubyClass computeValue(Class type) {
return new RubyClass(Ruby.this);
}
};
On 3/1/18 2:25 AM
exception chain?
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8086252
On Wed, Feb 28, 2018 at 12:40 PM Charles Oliver Nutter
<head...@headius.com <mailto:head...@headius.com>> wrote:
Hey, I'm still not sure how best to deal with this, bu
see
similar performance :)
Yes, performance is on a par with polluted profile. The benchmark [1]
measures non-inlined case for invokeinterface and MH.invokeBasic (3
invocations/iter):
LMF._4_lmf_fs20.020 ± 0.635 ns/op
LMF._4_lmf_mhs 18.360 ± 0.181 ns/op
Best regards,
Vladimir Iv
ode). There won't be any customization
applied (at least, at that particular call site) to a method handle
coming from a static final field.
Best regards,
Vladimir Ivanov
On Mon, Feb 19, 2018 at 12:36 PM, Wenlei Xie <wenlei@gmail.com
<mailto:wenlei@gmail.com>> wrote:
>
On 2/19/18 5:13 PM, Jochen Theodorou wrote:
On 19.02.2018 14:31, Vladimir Ivanov wrote:
[...]
CallSites are the best you can get (JITs treat CallSite.target as
constant and aggressively inlines through them), but you have to bind
CallSite instance either to invokedynamic call site or put
to the use cases you have in mind (like
JPA/JAXB).
Best regards,
Vladimir Ivanov
For example, if a JPA or JAXB implementation did use a static fields,
the code to call methods on a domain hierarchy of classes would look
like this:
public final class MyAccessors {
private static final
nstant MH).
Best regards,
Vladimir Ivanov
[1]
final class org.lmf.LMF$$Lambda$37 implements java.util.function.Function
...
Constant pool:
...
#19 = Methodref #15.#18//
org/lmf/LMF$Dog.getName:()Ljava/lang/String;
...
public java.lang.Object apply(java.lang.Object);
descr
e so no inlining happens. In that case [3] non-static
MethodHandles are on par (or even slightly faster):
LMF._4_lmf_fs avgt 10 20.020 ± 0.635 ns/op
LMF._4_lmf_mhs avgt 10 18.360 ± 0.181 ns/op
(scores for 3 invocations in a row.)
Best regards,
Vladimir Ivanov
[1] 715 126borg.lmf
n-constant MethodHandles.
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8174749
On 2/2/18 3:33 PM, John Rose wrote:
Vladimir Ivanov did some work a few years ago on MH customization for hot MH
instances. It’s in the system. That should get better results than what
regards,
Vladimir Ivanov
On 1/9/18 9:10 PM, Charles Oliver Nutter wrote:
Unfortunately this just happened in one build, but I thought I'd post it
here for posterity.
Unhandled Java exception: java.lang.InternalError:
identity_L=Lambda(a0:L/SpeciesData,a1:L,a2:L)=>{
[exec] t
Looks good!
Best regards,
Vladimir Ivanov
On 11/13/17 7:34 PM, Claes Redestad wrote:
Hi,
this patch factors out the BoundMethodHandle species data class
generation to a new ClassSpecializer facility.
While currently semantically neutral, this will make it possible
to reuse the facility
isn't it? ;-)), but now it's a corner
case.
Best regards,
Vladimir Ivanov
[1] 5 in total: int, long, float, double, Object
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
shouldn't observe
significant growth in their number at runtime (unless there are lots of
unique "erased" signatures present; that's where LF sharing can't help
now).
Hope it helps. FTR I covered some of those topics in details in my
j.l.i-related talk at JVMLS'15 [1].
Best regards,
e chain for all rows and
passing the value (from the table) explicitly should lead to a better
generated code.
Best regards,
Vladimir Ivanov
On 5/2/17 10:29 PM, Wenlei Xie wrote:
Hi,
We are implementing Lambda function with capture support in a SQL
Engine. We currently implement by compiling
Best regards,
Vladimir Ivanov
We have a user reporting metaspace getting filled up with LambdaForm
classes that have no instances. I would not expect this to happen given
that they're generated via AnonymousClassloader and we would need to
hold a reference to them to keep them alive.
I'm
int!
Best regards,
Vladimir Ivanov
On July 31, 2016 10:34:51 PM PDT, Vladimir Ivanov
<vladimir.x.iva...@oracle.com> wrote:
Thanks a lot for preparing the agenda, John!
I'd like to nominate a topic into API section: enable super constructor
lookups in j.l.i.
FTR it was discu
on it yet. Maybe it's
worth to reiterate the discussion as well?
Best regards,
Vladimir Ivanov
[1]
http://mail.openjdk.java.net/pipermail/mlvm-dev/2015-February/006292.html
On 7/31/16 10:13 PM, John Rose wrote:
Tomorrow at the JVMLS we will have an hour-long workshop to discuss indy
and MHs
as methods marked as non-compilable
due to profile pollution (e.g., JDK-8074551 [1]). I suggest to monitor
JIT compiler activity as well.
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8074551
On 5/31/16 10:41 PM, Mark Roos wrote:
I have been implementing
on
j.l.i.MethodHandleImpl.T.invoke_V was an overlook.
Best regards,
Vladimir Ivanov
On 5/11/16 3:59 PM, fo...@univ-mlv.fr wrote:
- Mail original -
De: "Vladimir Ivanov" <vladimir.x.iva...@oracle.com>
À: "Remi Forax" <fo...@univ-mlv.fr>, "shilpi rastogi"
<shilpi.rast...@o
Remi, I'm curious why doesn't @Hidden on the invoker method solve your
problem?
Best regards,
Vladimir Ivanov
On 5/11/16 3:44 PM, Remi Forax wrote:
Hi all,
changing the behavior of defineAnonymousClass in 9 is huge burden for me and i
believe for anybody that maintains a dynamic language
cate
application expectations to the JVM? Either always recompile (thus
eventually reaching peak performance) or give up and generate less
efficient machine code, but save on possible recompilations.
Best regards,
Vladimir Ivanov
On 1/20/16 2:37 AM, John Rose wrote:
On Jan 18, 2016, at 4:5
ovide bytecode intrinsics for tryFinally
and loop combinators in InvokerBytecodeGenerator to compile them in more
efficient bytecode shapes. If yes, please, file corresponding RFEs.
Best regards,
Vladimir Ivanov
On 11/13/15 7:39 PM, Michael Haupt wrote:
Dear all,
please review this change.
RFE:
exceptions there.
Best regards,
Vladimir Ivanov
On 6/17/15 1:19 PM, Konstantin Shefov wrote:
Hello,
Please review the test bug fix
https://bugs.openjdk.java.net/browse/JDK-8067005
Webrev is http://cr.openjdk.java.net/~kshefov/8067005/webrev.00/
Thanks
-Konstantin
Looks good.
Best regards,
Vladimir Ivanov
On 6/17/15 7:23 PM, Konstantin Shefov wrote:
Vladimir,
I have updated the webrev:
http://cr.openjdk.java.net/~kshefov/8067005/webrev.01/
-Konstantin
On 06/17/2015 04:01 PM, Vladimir Ivanov wrote:
Konstantin,
I'd move isThrowableCausedByVME
Puneet,
How did you end up with such bytecode? Was it generated by javac?
Rejecting access to a method which is not visible from the context where
invokedynamic is linked is the correct behavior.
Best regards,
Vladimir Ivanov
On 6/5/15 6:59 AM, Bansal, Puneet wrote:
Hi All
I got
+ * @ignore until 8078602 is fixed
The standard way to exclude a test is to mention bug ID.
Use the following:
@ignore 8078602
Otherwise, looks good.
Best regards,
Vladimir Ivanov
On 6/5/15 12:48 PM, Konstantin Shefov wrote:
Hello,
Please review the test bug fix
https
Good.
Best regards,
Vladimir Ivanov
On 6/5/15 1:05 PM, Konstantin Shefov wrote:
Vladimir
Thanks for reviewing
Here is corrected fix:
http://cr.openjdk.java.net/~kshefov/8068416/webrev.02
-Konstantin
On 06/05/2015 01:00 PM, Vladimir Ivanov wrote:
+ * @ignore until 8078602 is fixed
prefer the test to be excluded until
BMHs are converted to VM anonymous classes.
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8078602
On 6/4/15 12:10 PM, Konstantin Shefov wrote:
Igor,
It seems I have given you wrong information. This test fails with OOME
against JDK
Have you tried to reduce iteration granularity?
Probably, checking execution duration on every test case is more robust.
Best regards,
Vladimir Ivanov
On 5/27/15 5:50 PM, Konstantin Shefov wrote:
Hello,
Please review the test bug fix
https://bugs.openjdk.java.net/browse/JDK-8062904
Webrev
Looks good then!
Best regards,
Vladimir Ivanov
On 5/19/15 12:35 PM, Igor Ignatyev wrote:
Vladimir,
thank you for review.
regarding slot consumption calculation, to get parameters limited by
slot number, the test uses Helper.getParams method which implements this
calculation
(test/lib
Ok, now I see long.class in the list :-)
Does the test checks 255 limit on slots or logical arguments? It should
check slot size, but I don't see logic for computing slot consumption
for generated signatures.
Best regards,
Vladimir Ivanov
On 5/18/15 8:58 PM, Vladimir Ivanov wrote:
Igor
,
int.class,
byte.class,
Integer[].class,
double[].class,
String.class,
Best regards,
Vladimir Ivanov
On 5/18/15 8:51 PM, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev/8055269/webrev.00/
23 lines changed: 8 ins; 9 del; 6 mod
Hi
Thanks, Paul.
Best regards,
Vladimir Ivanov
On 4/23/15 6:30 PM, Paul Sandoz wrote:
On Apr 23, 2015, at 5:12 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
https://bugs.openjdk.java.net/browse/JDK-8059455
http://cr.openjdk.java.net/~vlivanov/8059455/webrev.00
Thanks, John.
Best regards,
Vladimir Ivanov
On 4/21/15 8:46 PM, John Rose wrote:
Reviewed. Nice find.
– John
On Apr 21, 2015, at 10:37 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8078290/webrev.00/
https://bugs.openjdk.java.net/browse/JDK
), microbenchmark,
jdk/test/java/lang/invoke, hotspot/test/compiler/jsr292, nashorn
Best regards,
Vladimir Ivanov
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Roland, thanks a lot for the review!
Best regards,
Vladimir Ivanov
On 4/15/15 7:43 PM, Roland Westrelin wrote:
http://cr.openjdk.java.net/~vlivanov/8057967/webrev.01/
That looks good to me.
Roland.
___
mlvm-dev mailing list
mlvm-dev
Roland, thanks for looking into the fix!
You are right.
I moved VM_ENTRY_MARK to the beginning of the method [1].
Updated webrev in place.
http://cr.openjdk.java.net/~vlivanov/8057967/webrev.01/
Best regards,
Vladimir Ivanov
[1]
diff --git a/src/share/vm/ci/ciCallSite.cpp b/src/share/vm/ci
and it
causes observable peak performance regression in some situations (e.g.
JRuby9K).
Testing: manual (microbenchmark, compilation log inspection).
Thanks!
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8069591
Customize LambdaForms which are invoked using
Any volunteers to review VM part?
Latest webrev:
http://cr.openjdk.java.net/~vlivanov/8057967/webrev.01/hotspot/
http://cr.openjdk.java.net/~vlivanov/8057967/webrev.01/jdk/
Best regards,
Vladimir Ivanov
On 4/1/15 11:56 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov
Peter,
Thanks for the exhaustive analysis.
Filed JDK-8076596 [1]
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8076596
On 3/30/15 11:01 PM, Peter Levart wrote:
Hi Max,
On 03/30/2015 05:24 PM, Wang Weijun wrote:
I have a customized security manager:
import
ClassLoader ccl = ClassLoader.getClassLoader(caller);
final ClassLoader cl = getClassLoader0();
if (which != Member.PUBLIC) {
if (ccl != cl) {
s.checkPermission(SecurityConstants.CHECK_MEMBER_ACCESS_PERMISSION);
}
Best regards,
Vladimir Ivanov
Aleksey, thanks a lot for the performance evaluation of the fix!
Best regards,
Vladimir Ivanov
On 4/2/15 7:10 PM, Aleksey Shipilev wrote:
On 04/01/2015 11:56 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8057967/webrev.00/hotspot/
http://cr.openjdk.java.net/~vlivanov/8057967
)?
DEFAULT_CONTEXT would then be a Cleaner instance that references some
default Class object (for example DefaultContext.class that serves no
other purpose).
Good idea! I eliminated the indirection as you suggest.
Best regards,
Vladimir Ivanov
___
mlvm-dev mailing
since MemberNames are
checked during construction.
The fix is to disable access checks when inlining DMH linkers.
Testing: regression test, java/lang/invoke tests, nashorn, octane.
Best regards,
Vladimir Ivanov
___
mlvm-dev mailing list
mlvm-dev
regards,
Vladimir Ivanov
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
::checkCustomized
call. It should be eliminated since it adds some overhead on fast path.
The fix is to add new intrinsic (MHI::isCompileConstant) and use it to
prune MHI::checkCustomized logic when MethodHandle is a constant.
Testing: java/lang/invoke, nashorn, octane
Best regards,
Vladimir
Thanks, John!
Will fix the typo before pushing the fix.
Best regards,
Vladimir Ivanov
On 3/16/15 9:51 PM, John Rose wrote:
Good fix, thanks. — John
P.S. I noticed a typo: it's (contraction of it is) should be its (genitive of
it).
On Mar 16, 2015, at 11:26 AM, Vladimir Ivanov
deopt in
MHI::profileBoolean and corresponding count becomes non-zero.
The guard doesn't add any additional overhead, since it dominates all
value usages and all branches on the same value are eliminated.
Testing: java/lang/invoke, nashorn, octane
Best regards,
Vladimir Ivanov
Thanks, John!
Best regards,
Vladimir Ivanov
On 3/16/15 10:05 PM, John Rose wrote:
Reviewed. — John
On Mar 16, 2015, at 11:47 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/hotspot
http://cr.openjdk.java.net/~vlivanov/8075263
Lev,
Have you tried passing -XDignore.symbol.file to javac?
Regarding the API, I'd recommend (if it's an appropriate word for
implementation-specific API :-)) to experiment with
Unsafe.defineAnonymousClass() instead.
Best regards,
Vladimir Ivanov
On 3/13/15 2:22 AM, Lev Serebryakov wrote
); }
finally { cleanup(ret, *a); } }
My point was that additional flexibility is probably too much, since it
can be achieved using other combinators.
Best regards,
Vladimir Ivanov
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http
on
-Djava.lang.invoke.MethodHandle.DEBUG_NAMES=true and calling
MethodHandle.toString() on a method handle of your choice.
Best regards,
Vladimir Ivanov
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm
, try -XX:PerBytecodeRecompilationCutoff=-1
-XX:PerMethodRecompilationCutoff=-1 (to workaround another problem I
spotted [1]).
On 3/4/15 5:16 AM, John Rose wrote:
On Mar 3, 2015, at 3:21 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Ah, I see now.
You suggest to conditionally
regards,
Vladimir Ivanov
On 3/3/15 2:12 PM, Marcus Lagergren wrote:
At the VM language summit at JFokus 2015, we discussed having ways to get new
dynamic language functions into the JVM without having to resort to generating
a class wrapping their byte code. A class is currently the smallest possible
manifests
itself). I'll let you know once I have a fix.
Best regards,
Vladimir Ivanov
- Charlie
On Fri, Mar 6, 2015 at 7:06 AM, Vladimir Ivanov
vladimir.x.iva...@oracle.com wrote:
John,
You are absolutely right. I should've spent more time exploring the code
than writing emails :-)
Here's
.
Best regards,
Vladimir Ivanov
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
happens here
...
In general, there could be other actions between ifeq
MHI.profileBoolean, so it's not possible to restore state and reexecute
the code starting from MHI.profileBoolean.
Am I missing something?
Best regards,
Vladimir Ivanov
___
mlvm-dev
Ah, I see now.
You suggest to conditionally insert uncommon trap in MHI.profileBoolean
when a count == 0, right?
Won't we end up with 2 checks if VM can't fold them (e.g. some action in
between)?
Best regards,
Vladimir Ivanov
On 3/4/15 2:15 AM, Vladimir Ivanov wrote:
Right now, VM
is that deopt counts pollution can force GWT method to
be marked as non-compilable. It seems I should go back to explicit hint
for JIT to avoid method profiling (e.g. @DontProfile).
I'm working on the fix for both problems and will file a bug shortly.
Best regards,
Vladimir Ivanov
[1] https
Thanks, Paul!
Best regards,
Vladimir Ivanov
On 2/27/15 1:03 PM, Paul Sandoz wrote:
On Feb 26, 2015, at 7:14 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8073644/webrev.00
https://bugs.openjdk.java.net/browse/JDK-8073644
After JDK-8069591 [1
. And
LambdaFormEditor.lambdaForm is always uncustomized.
Testing: java/lang/invoke, nashorn tests
Thanks!
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8069591
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http
the logs before make any
conclusions.
I'll keep you posted about my findings.
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8069591
On 2/26/15 2:53 AM, Charles Oliver Nutter wrote:
I'm finally at home with a working machine so I can follow up on some
VM Summit
together, if you don't have deep knowledge in the field.
Best regards,
Vladimir Ivanov
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Remi, thanks for the report!
Filed JDK-8072008 [1].
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8072008
On 1/30/15 4:03 AM, Remi Forax wrote:
On 01/30/2015 01:48 AM, John Rose wrote:
On Jan 7, 2015, at 8:13 AM, Remi Forax fo...@univ-mlv.fr
mailto:fo...@univ
Thanks, John!
Best regards,
Vladimir Ivanov
On 1/29/15 6:10 AM, John Rose wrote:
Good. Consider fixing the typo in 'makeBlockInlningWrapper'. — John
On Jan 28, 2015, at 9:12 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8071787/webrev.00
Thanks, John!
Best regards,
Vladimir Ivanov
On 1/29/15 6:11 AM, John Rose wrote:
Good.
On Jan 28, 2015, at 9:22 AM, Vladimir Ivanov
vladimir.x.iva...@oracle.com mailto:vladimir.x.iva...@oracle.com wrote:
The fix is to use adapted MethodHandle to construct LambdaForm
decide to generalize the
API, I'd be happy to remove it, but current usages assumes that injected
counts are always consumed during parsing and missing cases can cause
hard-to-diagnose performance problems.
Best regards,
Vladimir Ivanov
(Generally speaking, pattern matching should assume
of java.lang.invoke code, and there are no such
calls inside it.
Testing: manual, java/lang/invoke
Thanks!
Best regards,
Vladimir Ivanov
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
in
has_injected_profile();
- added BoolTest::ne support
- sharpened test for AndI case: now it checks AndI (ProfileBoolean)
(ConI 1) shape
Best regards,
Vladimir Ivanov
On 1/27/15 3:04 AM, John Rose wrote:
On Jan 26, 2015, at 8:41 AM, Vladimir Ivanov
vladimir.x.iva...@oracle.com
to
the deoptimization counts pollution. What do you prefer?
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8068915
On 1/23/15 4:31 AM, John Rose wrote:
On Jan 20, 2015, at 11:09 AM, Vladimir Ivanov
vladimir.x.iva...@oracle.com mailto:vladimir.x.iva...@oracle.com wrote:
What I'm
to that change (there's a 10% difference in peak performance
between @Shared and has_injected_profile()).
Ignore that. Additional runs don't prove there's a regression on Gbemu.
There's some variance on Gbemu and it's present w/ and w/o @Shared.
Best regards,
Vladimir Ivanov
I can leave @Shared
Good idea, Peter!
Updated version:
http://cr.openjdk.java.net/~vlivanov/8069591/webrev.02/
Best regards,
Vladimir Ivanov
On 1/23/15 5:38 PM, Peter Levart wrote:
On 01/23/2015 12:30 AM, John Rose wrote:
On Jan 22, 2015, at 9:56 AM, Vladimir Ivanov
vladimir.x.iva...@oracle.com wrote:
Remi
hope it is not necessary any
more. That said, I agree that the pattern should be consistent.
Sure. Here is it [1]
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8071368
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http
Duncan, sorry for that.
Updated webrev inplace.
Best regards,
Vladimir Ivanov
On 1/21/15 1:39 PM, MacGregor, Duncan (GE Energy Management) wrote:
This version seems to have inconsistent removal of ignore profile in the
hotspot patch. It’s no longer added to vmSymbols but is still referenced
in steady state w/ Action_none.
Also, there's deoptimization statistics in the log (at least, in jdk9).
It's located right before compilation_log tag.
Thanks again for the valuable feedback!
Best regards,
Vladimir Ivanov
[1] http://cr.openjdk.java.net/~vlivanov/8068915/webrev.00
On 1/19/15 11:21
John, thanks for the review!
Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8063137/webrev.01/hotspot
http://cr.openjdk.java.net/~vlivanov/8063137/webrev.01/jdk
See my answers inline.
On 1/17/15 2:13 AM, John Rose wrote:
On Jan 16, 2015, at 9:16 AM, Vladimir Ivanov
vladimir.x.iva
::inline_profileBranch(). Changes in macro.cpp
compile.cpp are leftovers from the version when Opaque4 was macro node.
I plan to remove them.
Best regards,
Vladimir Ivanov
On 1/16/15 9:16 AM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8063137/webrev.00/hotspot/
http://cr.openjdk.java.net
]. There's one more problem left (non-inlined MethodHandle invocations
are more expensive when LFs are shared), but it's a story for another day.
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8059877
8059877: GWT branch frequencies pollution due to LF sharing
[2
Thanks, Paul!
Best regards,
Vladimir Ivanov
On 1/12/15 9:42 PM, Paul Sandoz wrote:
On Jan 12, 2015, at 7:06 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Paul,
Thanks for the review!
Look good, +1,
Paul.
Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8067344/webrev.02
,
TestMethods.Kind.ONE);
Could replace getTestMethod() with testCase.
Done.
Best regards,
Vladimir Ivanov
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
,
Vladimir Ivanov
On 12/24/14 3:20 PM, Peter Levart wrote:
Hi Vladimir,
I just wanted to ask about the reason you used PhantomReference to
detect that a referent is not softly reachable any more. You could use
another SoftReference or a WeakReference for the same effect, since it
is guaranteed that all
:
http://cr.openjdk.java.net/~vlivanov/8067344/webrev.01/
Best regards,
Vladimir Ivanov
On 12/22/14 11:53 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8067344/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8067344
LFGarbageCollectedTest should be adjusted after JDK-8057020
diagnostic output to simplify failure analysis
(test case details, method handle type and LambdaForm, heap dump
(optional, -DHEAP_DUMP=true)).
Testing: failing test.
Thanks!
Best regards,
Vladimir Ivanov
___
mlvm-dev mailing list
mlvm-dev
John, Paul, thanks for the reviews!
Looks ok.
Curiously, is there a reason why you chose to use MH.invokeWithArguments rather
than MH.invoke/invokeExact?
No particular reason. Just didn't want to want to spend time tuning call
site for signature polymorphic method.
Best regards,
Vladimir
(30x more instantiated
LambdaForms- from 1-3k to 30k-60k on Octane/Nashorn).
So, SoftReferences look like a good fit.
Best regards,
Vladimir Ivanov
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
in MethodTypeForm is built on that property. For the reference, we had
discussed this aspect before (scattered in [1]).
Best regards,
Vladimir Ivanov
[1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-May/013902.html
___
mlvm-dev mailing list
mlvm
to be a pairwise argument and return type conversion.
The fix is to ensure that adapted method handle has fixed arity.
Testing: regression test, jck (api/java_lang/invoke), jdk/java/lang/invoke
Thanks!
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8057656
tests in long running
mode.
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8060147
On 12/3/14, 3:11 PM, Aleksey Shipilev wrote:
On 12/01/2014 07:58 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
https://bugs.openjdk.java.net
Thanks, Paul!
Updated webrev in place.
On Dec 1, 2014, at 5:58 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8057020
That LambdaFormEditor.putInCache method just got more gnarly
and rewrite this
logic once support in jtreg is implemented.
Otherwise, looks good.
Best regards,
Vladimir Ivanov
Paul.
On Nov 29, 2014, at 5:36 PM, Igor Ignatyev igor.ignat...@oracle.com wrote:
http://cr.openjdk.java.net/~iignatyev/8039953/webrev.00
98 lines changed: 93 ins; 3 del; 2 mod
Looks good.
Best regards,
Vladimir Ivanov
On 12/1/14, 10:58 PM, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev/8039953/webrev.01/
to have TimeLimitedRunner more general, I've added 'factor' argument to
its ctor.
Thanks,
Igor
On 12/01/2014 02:39 PM, Igor Ignatyev wrote:
Paul
Looks good.
Best regards,
Vladimir Ivanov
On 11/19/14, 3:12 PM, Konstantin Shefov wrote:
Hello, Vladimir
I have updated the Webrev
http://cr.openjdk.java.net/~kshefov/8059070/webrev.02
I have added DEFAULT_TEST_TIMEOUT constant to Utils class.
-Konstantin
On 13.11.2014 15:48, Konstantin
Paul, Aleksey, thanks for review!
Best regards,
Vladimir Ivanov
On 11/20/14, 8:23 PM, Paul Sandoz wrote:
On Nov 19, 2014, at 10:30 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Hm, I remember I fixed that long time ago... Seems like I chose a stale patch.
Sorry for that. Updated
Aleksey, Duncan, thanks for the review and the confirmation that it
doesn't break stuff for you.
Any Reviews, please? :-)
Best regards,
Vladimir Ivanov
On 11/19/14, 2:23 PM, MacGregor, Duncan (GE Energy Management) wrote:
On 18/11/2014 23:33, Aleksey Shipilev aleksey.shipi...@oracle.com
Hm, I remember I fixed that long time ago... Seems like I chose a stale
patch. Sorry for that. Updated webrev in place.
Best regards,
Vladimir Ivanov
On 11/19/14, 3:38 AM, Aleksey Shipilev wrote:
On 11/18/2014 11:23 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8063135
Thanks, Vladimir!
Best regards,
Vladimir Ivanov
On 11/19/14, 9:20 PM, Vladimir Kozlov wrote:
As far as I can guess :) this change looks good. Reviewed.
Thanks,
Vladimir
On 11/19/14 2:24 AM, Vladimir Ivanov wrote:
Aleksey, Duncan, thanks for the review and the confirmation that it
doesn't
].
Testing: jck (api/java_lang/invoke), jdk/java/lang/invoke,
jdk/java/util/streams, octane
Thanks!
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8059877
[2] https://bugs.openjdk.java.net/browse/JDK-8063137
___
mlvm-dev mailing
1 - 100 of 224 matches
Mail list logo