gmane.comp.java.openjdk.hotspot.compiler.devel

hg: jdk7/hotspot-comp/hotspot: 5 new changesets

2010-03-18T17:56:05

Changeset: d47555d7aca8
Author:    jmasa
Date:      2010-03-03 08:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d47555d7aca8

6910182: CMS: assert(_cursor[j] == _survivor_plab_array[j].end(),"Ctl pt invariant")
Summary: Calculation of the slicing of survivor spaces for MT was incorrect.
Reviewed-by: ysr

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp

Changeset: c8a467bf56ad
Author:    coleenp
Date:      2010-03-02 12:09 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c8a467bf56ad

6914050: jvm assertion "guard pages must be in use" in -Xcomp mode
Summary: Move creating stack guard pages in jni attach thread before potential java call rather than after. Also cleanup stack guard pages when jni attach fails
Reviewed-by: never, dholmes

! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/thread.cpp

Changeset: 4b0f2f4918ed
Author:    xlu
Date:      2010-03-10 21:42 -0800
URL:       http://hg.openjdk.java.net/jdk7/ho

hg: jdk7/hotspot-comp/hotspot: 6932091: JSR 292 x86 code cleanup

2010-03-18T13:27:25

Changeset: 76c1d7d13ec5
Author:    twisti
Date:      2010-03-18 09:56 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/76c1d7d13ec5

6932091: JSR 292 x86 code cleanup
Summary: Some code cleanups found during the JSR 292 SPARC port.
Reviewed-by: kvn, never

! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/arguments.cpp

hg: jdk7/hotspot-comp/hotspot: 6930043: C2: SIGSEGV injavasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I

2010-03-18T01:42:10

Changeset: c047da02984c
Author:    never
Date:      2010-03-17 16:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c047da02984c

6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I
Reviewed-by: kvn

! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopnode.hpp
+ test/compiler/6930043/Test6930043.java

Re: Request for reviews (M): 6932091: JSR 292 x86 code cleanup

Tom Rodriguez — 2010-03-17T21:11:38

Looks good.

tom

On Mar 17, 2010, at 5:40 AM, Christian Thalinger wrote:

hg: jdk7/hotspot-comp/hotspot: 6935535: String.indexOf() returnsincorrect result on x86 with SSE4.2

2010-03-17T20:22:53

Changeset: 2484f4d6a54e
Author:    kvn
Date:      2010-03-17 10:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2484f4d6a54e

6935535: String.indexOf() returns incorrect result on x86 with SSE4.2
Summary: Added missing counter decrement when substring search restarted.
Reviewed-by: twisti

! src/cpu/x86/vm/assembler_x86.cpp
+ test/compiler/6935535/Test.java

Re: Request for reviews (M): 6932091: JSR 292 x86 code cleanup

Vladimir Kozlov — 2010-03-17T17:43:48

Looks good.

Vladimir

Christian Thalinger wrote:

Re: review (S) for 6930043: C2: SIGSEGV injavasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I

Vladimir Kozlov — 2010-03-17T17:36:15

Looks good.

Vladimir

Tom Rodriguez wrote:
 fore.  I've updated the webrev.

Re: review (S) for 6930043: C2: SIGSEGV injavasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I

Tom Rodriguez — 2010-03-17T17:06:37

It's updated now.

tom

On Mar 16, 2010, at 1:59 PM, Vladimir Kozlov wrote:

 ore.  I've updated the webrev.

Re: Request for reviews (XS): 6935535: String.indexOf() returnsincorrect result on x86 with SSE4.2

Vladimir Kozlov — 2010-03-17T16:32:44

Thank you, Christian

Vladimir

Christian Thalinger wrote:

hg: jdk7/hotspot-comp/hotspot: 6934966: JSR 292 add C1 logic forsaved SP over MethodHandle calls

2010-03-17T14:24:56

Changeset: fc2c71045ada
Author:    twisti
Date:      2010-03-17 10:22 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fc2c71045ada

6934966: JSR 292 add C1 logic for saved SP over MethodHandle calls
Summary: The logic for x86 C1 to save the SP over MH calls is pretty straight forward but SPARC handles that differently.
Reviewed-by: never, jrose

! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/x86/vm/c1_FrameMap_x86.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/c1/c1_LIRAssembler.hpp

Re: Request for reviews (XS): 6935535: String.indexOf() returnsincorrect result on x86 with SSE4.2

Christian Thalinger — 2010-03-17T12:44:18

Looks good.  -- Christian

Request for reviews (M): 6932091: JSR 292 x86 code cleanup

Christian Thalinger — 2010-03-17T12:40:30

http://cr.openjdk.java.net/~twisti/6932091/webrev.01/

Some code cleanups found during the JSR 292 SPARC port.

Additionally TaggedStackInterpreter is disabled when MethodHandles are
enabled as the MethodHandles code does not support
TaggedStackInterpreter.

src/cpu/x86/vm/methodHandles_x86.cpp
src/cpu/x86/vm/templateTable_x86_32.cpp
src/cpu/x86/vm/templateTable_x86_64.cpp
src/share/vm/c1/c1_LIRGenerator.cpp
src/share/vm/prims/methodHandles.hpp
src/share/vm/runtime/arguments.cpp

Request for reviews (XS): 6935535: String.indexOf() returns incorrectresult on x86 with SSE4.2

Vladimir Kozlov — 2010-03-17T02:15:29

http://cr.openjdk.java.net/~kvn/6935535/webrev

Fixed 6935535: String.indexOf() returns incorrect result on x86 with SSE4.2

Added missing counter decrement when substring search restarted.
Added regression test.

hg: jdk7/hotspot-comp/hotspot: 6935466: new CodeCache flushing codeis not guarded by the flag

2010-03-17T01:08:52

Changeset: 428a9c451986
Author:    kvn
Date:      2010-03-16 15:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/428a9c451986

6935466: new CodeCache flushing code is not guarded by the flag
Summary: Add missing guard.
Reviewed-by: never

! src/share/vm/compiler/compileBroker.cpp

Re: Request for reviews (XS): 6931465: Switch off by defaultoptimization flags in HS17]

Vladimir Kozlov — 2010-03-16T22:34:48

Thanks, Tom

Vladimir

Tom Rodriguez wrote:

Re: Request for reviews (XS): 6931465: Switch off by defaultoptimization flags in HS17]

Tom Rodriguez — 2010-03-16T22:32:11

Looks good.

tom

On Mar 16, 2010, at 3:04 PM, Vladimir Kozlov <Vladimir.Kozlov-UdXhSnd/wVw< at >public.gmane.org>  
wrote:

Request for reviews (XS): 6931465: Switch off by default optimizationflags in HS17]

Vladimir Kozlov — 2010-03-16T22:04:50

http://cr.openjdk.java.net/~kvn/6935466/webrev

Fixed 6935466: new CodeCache flushing code is not guarded by the flag

Add missing guard.

Re: review (S) for 6930043: C2: SIGSEGV injavasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I

Vladimir Kozlov — 2010-03-16T20:59:01

Yes, I was wrong, it is inserted in between. The assert is good.
But I don't see updated comment and hash_delete() calls.

Vladimir

Tom Rodriguez wrote:
 re.  I've updated the webrev.

Re: review (S) for 6930043: C2: SIGSEGV injavasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I

Tom Rodriguez — 2010-03-16T18:39:06

On Mar 16, 2010, at 11:17 AM, Vladimir Kozlov wrote:


create_new_if_for_predicate inserts a new if between the trap place holder if and the last created if.  I'd added an assert that verified the ordering but I guess I never updated the webrev itself.  It's there now and it looks like this:

+       assert(upper_bound_proj->in(0)->as_If()->in(0) == lower_bound_proj, "should dominate");

tom

 e.  I've updated the webrev.

Re: review (S) for 6930043: C2: SIGSEGV injavasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I

Vladimir Kozlov — 2010-03-16T18:17:59


Tom Rodriguez wrote:

Then you have to swap next lines, otherwise upper_bound will be generated above lower_bound

2267       ProjNode* lower_bound_proj = create_new_if_for_predicate(predicate_proj);
2268       ProjNode* upper_bound_proj = create_new_if_for_predicate(predicate_proj);

Vladimir

 .  I've updated the webrev.

Re: review (S) for 6930043: C2: SIGSEGV injavasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I

Tom Rodriguez — 2010-03-16T18:09:55

On Mar 16, 2010, at 10:46 AM, Vladimir Kozlov wrote:


Why?  That's not the usage model of create_new_if_for_predicate.

ProjNode* PhaseIdealLoop::create_new_if_for_predicate(ProjNode* cont_proj) {
  assert(is_uncommon_trap_if_pattern(cont_proj, true), "must be a uct if pattern!");

I think it would assert if I passed something else and it wouldn't improve the code shape even if I did.


ok.



Calling hash_delete implies something which isn't true about the nodes since they are newly created and I found it confusing when I first read it which is why I removed it.  I guess it would be more consistent with the other code in loop opts which pretty much always calls hash_delete.  I'll restore it.

tom

   I've updated the webrev.