Changeset: 7d236a9688c5 Author: never Date: 2010-03-01 12:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7d236a9688c5 6930398: fix for return address locals in OSR entries uses wrong test Reviewed-by: kvn ! src/share/vm/opto/parse1.cpp
Having following code:
public String(int[] codePoints, int offset, int count) {
...
int n = 0;
for (int i = offset; i < offset + count; i++) {
int c = codePoints[i];
if (c >> 16 == 0)
n += 1;
else if ((c >> 16) < (Character.MAX_CODE_POINT + 1 >> 16))
n += 2;
else
throw new IllegalArgumentException(Integer.toString(c));
}
...
}
It compiles to:
-> int c = codePoints[i];
0x00b87aa4: mov 0x1c(%esp),%ebp
0x00b87aa8: mov 0xc(%ebp,%edi,4),%ebx ;*iaload
; -
java.lang.String::<init> <at> 72 (line 284)
-> if (c >> 16 == 0)
0x00b87aac: mov %ebx,%ecx
0x00b87aae: sar $0x10,%ecx ;*ishr
; -
java.lang.String::<init> <at> 79 (line 290)
(Continue reading)
Changeset: b81f3572f355 Author: tonyp Date: 2010-02-23 23:13 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b81f3572f355 6928059: G1: command line parameter renaming Summary: Rename G1 parameters to make them more consistent. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 1c72304f1885 Author: tonyp Date: 2010-02-23 23:14 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1c72304f1885 6928073: G1: use existing command line parameters for marking cycle initiation Summary: replace the combination of the G1SteadyStateUsed / G1SteadyStateUsedDelta parameteres to decide the marking initiation threshold and instead use InitiatingHeapOccupancyPercent. Reviewed-by: ysr, johnc(Continue reading)
http://cr.openjdk.java.net/~twisti/6932536/webrev.01/ Changing the nextArg value of MethodHandlesTest to be bigger than Integer.MAX_VALUE to actually test long arguments reveals a bug on x86_64. There were actually two bugs: 1. For i2l and unboxi long values were stored in two slots as 32-bit words instead of a 64-bit one. 2. The stack-move conversion value was read as 32-bit value and then shifted which resulted in e.g. 0xffffffff values in 64-bit registers instead of -1. Tested: MethodHandlesTest
Looks good. tom On Mar 5, 2010, at 7:30 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6932536/webrev.01/ > > Changing the nextArg value of MethodHandlesTest to be bigger than > Integer.MAX_VALUE to actually test long arguments reveals a bug on > x86_64. > > There were actually two bugs: > > 1. For i2l and unboxi long values were stored in two slots as 32-bit > words instead of a 64-bit one. > > 2. The stack-move conversion value was read as 32-bit value and then > shifted which resulted in e.g. 0xffffffff values in 64-bit registers > instead of -1. > > Tested: MethodHandlesTest >
http://cr.openjdk.java.net/~roland/6932496/webrev.00/
Looks good. tom On Mar 5, 2010, at 11:42 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/6932496/webrev.00/ >
On Mar 5, 2010, at 7:30 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6932536/webrev.01/ Looks good; thanks. And thanks for extending the test suite! -- John P.S. I wish we could factor those ifdefs into the assembler. It would be possible (as it is on SPARC) if x86_32 allowed 64-bit values in one register. Perhaps there's a way to hide the distinction between a movq and two movl's (along with the tagged-stack-interpreter stuff) in an assembler macro. I think it would require an ADT which encapsulates either a single 64-bit reg or a pair of 32-bit regs (depending in CPU mode). That's not worth the effort. But on SPARC, we should expect to have fewer ifdefs.
On Fri, 2010-03-05 at 16:51 -0800, John Rose wrote: > On Mar 5, 2010, at 7:30 AM, Christian Thalinger wrote: > > > http://cr.openjdk.java.net/~twisti/6932536/webrev.01/ > > Looks good; thanks. And thanks for extending the test suite! > > -- John > > P.S. I wish we could factor those ifdefs into the assembler. It > would be possible (as it is on SPARC) if x86_32 allowed 64-bit values > in one register. Perhaps there's a way to hide the distinction > between a movq and two movl's (along with the tagged-stack-interpreter > stuff) in an assembler macro. I think it would require an ADT which > encapsulates either a single 64-bit reg or a pair of 32-bit regs > (depending in CPU mode). That's not worth the effort. Would be nice to have. But as you say, not worth the effort... > But on SPARC, we should expect to have fewer ifdefs. I try to. -- Christian
Changeset: 51db1e4b379d Author: twisti Date: 2010-03-08 04:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/51db1e4b379d 6932536: JSR 292 modified JDK MethodHandlesTest fails on x86_64 Summary: A modified MethodHandlesTest revealed two bugs on x86_64. Reviewed-by: never, jrose ! src/cpu/x86/vm/methodHandles_x86.cpp
RSS Feed201 | |
|---|---|
336 | |
250 | |
242 | |
199 | |
286 | |
222 | |
206 | |
213 | |
162 | |
148 | |
196 | |
125 | |
111 | |
106 | |
226 | |
183 | |
121 | |
153 | |
177 | |
209 | |
186 | |
154 | |
178 | |
346 | |
232 | |
308 | |
122 | |
143 | |
138 | |
159 | |
153 | |
220 | |
142 | |
127 | |
188 | |
120 | |
232 | |
121 | |
201 | |
278 | |
175 | |
110 | |
135 | |
133 | |
261 | |
178 | |
78 | |
131 | |
200 | |
197 | |
205 | |
67 | |
44 | |
47 | |
43 | |
49 | |
30 | |
50 | |
36 | |
48 | |
43 | |
40 | |
6 | |
11 | |
8 | |
14 | |
3 | |
3 | |
13 | |
1 | |
6 | |
6 | |
1 | |
1 |
