Looks good.
Vladimir
Christian Thalinger wrote:
http://cr.openjdk.java.net/~twisti/7001363/webrev.01/
7001363: java/dyn/InvokeDynamic should not be a well-known class in the JVM
Summary: Because of the removal of language support, the JDK 7 API for JSR
292 no longer includes a public
java/lang/invoke/MethodTypeForm.java
double c != void.cl check:
+if (c == void.class)
+c = null; // a Void parameter was unwrapped to void; ignore
+if (c != null c != void.class) {
Otherwise looks good as far as I understand.
Vladimir
John Rose wrote:
Christian,
You need to add big comment to the new code in templateTable_arch.cpp
explaining what it does and why.
Why on sparc you use ld_ptr() to load from cache but on X86 and X64 you use
movl() (only 32 bit)?
Add assert(byte_no == -1, ) to default: case to make sure you got all cases
Christian,
Should we put skip bytecode quickening code under flag to do this only when
invoke dynamic is enabled? Or put_code is
zero only in invoke dynamic case?
On 8/8/11 6:56 AM, Christian Thalinger wrote:
Why on sparc you use ld_ptr() to load from cache but on X86 and X64 you use
movl()
Christian Thalinger wrote:
On Aug 8, 2011, at 4:55 PM, Vladimir Kozlov wrote:
Christian,
Should we put skip bytecode quickening code under flag to do this only
when invoke dynamic is enabled? Or put_code is zero only in invoke dynamic
case?
No, it doesn't buy us anything. The new
Tom Rodriguez wrote:
On Aug 8, 2011, at 11:52 AM, Vladimir Kozlov wrote:
Christian Thalinger wrote:
On Aug 8, 2011, at 4:55 PM, Vladimir Kozlov wrote:
Christian,
Should we put skip bytecode quickening code under flag to do this only
when invoke dynamic is enabled? Or put_code is zero
c1_GraphBuilder.cpp, can you remove setting bailout message for forced
inlining?
It should be done proper uniform way for C1 inlining later.
I think, next assert should check (id = _unknown id _annotation_LIMIT)
instead:
+void set_annotation(ID id) {
+ assert((int)id 0 (int)id
; thanks.
On Jul 11, 2012, at 2:35 PM, Vladimir Kozlov wrote:
c1_GraphBuilder.cpp, can you remove setting bailout message for forced
inlining? It should be done proper uniform way for C1 inlining later.
Done.
I think, next assert should check (id = _unknown id
_annotation_LIMIT
This looks good.
Thanks,
Vladimir
On 7/11/12 11:54 PM, John Rose wrote:
On Jul 11, 2012, at 5:25 PM, Vladimir Kozlov wrote:
But I'll change it if you insist.
Please, change. Also put final klass settings Fill in field values from
parse_classfile_attributes in a separate
ClassFileParser
John,
sharedRuntime_sparc.cpp:
Why casting to (int)? Also use pointer_delta(code_end, code_start,1):
+ __ set((int)(intptr_t)(code_end - code_start), temp2_reg);
You bound L_fail label twice, it should be local in range_check(). Use brx()
instead of br() since you compare pointers. And use
BoundMethodHandle.java:
I am concern that BMH subclass names are looks like constants names:
BMH_LLI.
In several places you have BMH constants and variables:
+ final ClassBoundMethodHandle BMH = BoundMethodHandle.class;
+ static final String BMH = java/lang/invoke/BoundMethodHandle;
to remove it? ;-)
No, you can leave it as it is.
Vladimir
Christian Thalinger wrote:
On Jul 12, 2012, at 6:27 PM, Vladimir Kozlov wrote:
John,
sharedRuntime_sparc.cpp:
Why casting to (int)? Also use pointer_delta(code_end, code_start,1):
+ __ set((int)(intptr_t)(code_end - code_start
Nice.
Vladimir
Christian Thalinger wrote:
We forgot to remove the Ricochet Frame code from the sA:
http://cr.openjdk.java.net/~twisti/7023639/
-- Chris
On Jul 19, 2012, at 11:28 AM, Christian Thalinger wrote:
JDK testing found a small bug:
diff --git
John,
Both webrevs point to jdk changes. Where are hotspot changes?
Vladimir
John Rose wrote:
On Jul 13, 2012, at 2:41 AM, John Rose wrote:
Here is that webrev:
http://cr.openjdk.java.net/~jrose/7023639/webrev.jdk.00/
These are the changes to JDK code that accompany the JVM changes
I am working on it.
Vladimir
On Oct 20, 2012, at 9:39 AM, Florian Weimer wrote:
* Remi Forax:
Even a simple code like the one below, there is no scalar replacement
(OSR or not),
Float f = new Float(0);
for(int i=0; ilength; i++) {
f = new Float(f + 1.0f);
}
Hi Charlie,
If you want to experiment :) you can try the code Roland and Christian
pushed.
Roland just pushed Incremental inlining changes for C2 which should help
LF inlining:
http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d092d1b31229
You also need Christian's inlining related
JRuby loads about 4000 own classes (above 1000 of system classes) during
execution of just '-e 1'. It is a lot of data to load, parse, verify.
I played with CDS (Class Data Sharing) which includes jruby classes. We
can do that since jruby.jar is on boot class path but it requires some
manual
Looks fine to me.
Can you push it into our jdk9/hs-comp/jdk repo so we can see immediate results
from it in our testing?
Thanks,
Vladimir
On 10/3/14 7:12 AM, Vladimir Ivanov wrote:
Updated version:
http://cr.openjdk.java.net/~vlivanov/8058892/webrev.02/
Looks good.
Thanks, Aleksey.
Any
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
break stuff for you.
Any Reviews, please? :-)
Best regards,
Vladimir Ivanov
On 11/19/14, 2:23
Nice! At least Hotspot part since I don't understand jdk part :)
I would suggest to add more detailed comment (instead of simple Stop
profiling) to inline_profileBranch() intrinsic explaining what it is
doing because it is not strictly intrinsic - it does not implement
profileBranch() java
Good.
thanks,
Vladimir K
On 3/16/15 12: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/webrev.00/jdk
You already have 'result' variable for argument(0), why reread?:
CmpINode(argument(0)
Usually IfTrue is the fast path. IGVN will revert that check to have
that. But it is better to have it in code. Current code looks like
double negation.
There is no explanation in changes why false_count
Looks fine to me.
Vladimir K
On 3/23/15 5:27 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8062280/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8062280
C2 inlining policy is too strict when it comes to inlining DMH linkers.
The compiler performs access checks on
23 matches
Mail list logo
