Christian Thalinger | 4 Jan 17:54 2011
Picon

Request for reviews (S): 7010180: JSR 292 InvokeDynamicPrintArgs fails with: assert(_adapter == NULL) failed: init'd to NULL

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

7010180: JSR 292 InvokeDynamicPrintArgs fails with: assert(_adapter == NULL) failed: init'd to NULL
Reviewed-by:

Since 7007377 during method handles adapter generation the adapters
for sun.dyn.MethodHandleImpl::raiseException are also generated.
Later when the Rewriter wants to link the method the adapter entry
already exists and the assert triggers.

The fix is to link sun.dyn.MethodHandleImpl class before generating
the method handle adapters.  This ensures that the required
c2i-adapter exists.

Tom Rodriguez | 4 Jan 18:06 2011
Picon

Re: Request for reviews (S): 7010180: JSR 292 InvokeDynamicPrintArgs fails with: assert(_adapter == NULL) failed: init'd to NULL


On Jan 4, 2011, at 8:54 AM, Christian Thalinger wrote:

> http://cr.openjdk.java.net/~twisti/7010180/webrev.01/
> 
> 7010180: JSR 292 InvokeDynamicPrintArgs fails with: assert(_adapter == NULL) failed: init'd to NULL
> Reviewed-by:
> 
> Since 7007377 during method handles adapter generation the adapters
> for sun.dyn.MethodHandleImpl::raiseException are also generated.
> Later when the Rewriter wants to link the method the adapter entry
> already exists and the assert triggers.
> 
> The fix is to link sun.dyn.MethodHandleImpl class before generating
> the method handle adapters.  This ensures that the required
> c2i-adapter exists.

That looks good.

tom

Christian Thalinger | 4 Jan 19:46 2011
Picon

Re: Request for reviews (S): 7010180: JSR 292 InvokeDynamicPrintArgs fails with: assert(_adapter == NULL) failed: init'd to NULL

On Jan 4, 2011, at 6:06 PM, Tom Rodriguez wrote:
> 
> On Jan 4, 2011, at 8:54 AM, Christian Thalinger wrote:
> 
>> http://cr.openjdk.java.net/~twisti/7010180/webrev.01/
>> 
>> 7010180: JSR 292 InvokeDynamicPrintArgs fails with: assert(_adapter == NULL) failed: init'd to NULL
>> Reviewed-by:
>> 
>> Since 7007377 during method handles adapter generation the adapters
>> for sun.dyn.MethodHandleImpl::raiseException are also generated.
>> Later when the Rewriter wants to link the method the adapter entry
>> already exists and the assert triggers.
>> 
>> The fix is to link sun.dyn.MethodHandleImpl class before generating
>> the method handle adapters.  This ensures that the required
>> c2i-adapter exists.
> 
> That looks good.

Thank you, Tom.  -- Christian
Vladimir Kozlov | 6 Jan 01:17 2011
Picon

Request for reviews (XS): 6876037: CTW fails jdk7/hotspot/src/share/vm/opto/type.cpp:2055. assert(bits,"Use TypePtr for NULL")

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

Fixed 6876037: CTW fails jdk7/hotspot/src/share/vm/opto/type.cpp:2055. assert(bits,"Use TypePtr
for NULL")

Missing 0 value check in TypeRawPtr::add_offset().

CastX2P node in address expression for unsafe memory operation
AddP(top, (CastX2P(SubI(3, loop_phi)), long) transformed into
AddP(top, ConP#3, SubI(0, loop_phi)):

for (int idx = 0; idx < 4; idx++) {
   unsafe.putByte(bufptr + (3-idx), b);

After loop full unroll this expression transformed
into AddP(top, ConP#3, -3). We hit assert during type
calculation for this node.

Tom Rodriguez | 6 Jan 01:33 2011
Picon

Re: Request for reviews (XS): 6876037: CTW fails jdk7/hotspot/src/share/vm/opto/type.cpp:2055. assert(bits, "Use TypePtr for NULL")

Looks ok.

tom

On Jan 5, 2011, at 4:17 PM, Vladimir Kozlov wrote:

> http://cr.openjdk.java.net/~kvn/6876037/webrev
> 
> Fixed 6876037: CTW fails jdk7/hotspot/src/share/vm/opto/type.cpp:2055. assert(bits,"Use TypePtr
for NULL")
> 
> Missing 0 value check in TypeRawPtr::add_offset().
> 
> CastX2P node in address expression for unsafe memory operation
> AddP(top, (CastX2P(SubI(3, loop_phi)), long) transformed into
> AddP(top, ConP#3, SubI(0, loop_phi)):
> 
> for (int idx = 0; idx < 4; idx++) {
>  unsafe.putByte(bufptr + (3-idx), b);
> 
> After loop full unroll this expression transformed
> into AddP(top, ConP#3, -3). We hit assert during type
> calculation for this node.

Vladimir Kozlov | 6 Jan 01:36 2011
Picon

Re: Request for reviews (XS): 6876037: CTW fails jdk7/hotspot/src/share/vm/opto/type.cpp:2055. assert(bits,"Use TypePtr for NULL")

Thank you, Tom

Vladimir

Tom Rodriguez wrote:
> Looks ok.
> 
> tom
> 
> On Jan 5, 2011, at 4:17 PM, Vladimir Kozlov wrote:
> 
>> http://cr.openjdk.java.net/~kvn/6876037/webrev
>>
>> Fixed 6876037: CTW fails jdk7/hotspot/src/share/vm/opto/type.cpp:2055. assert(bits,"Use
TypePtr for NULL")
>>
>> Missing 0 value check in TypeRawPtr::add_offset().
>>
>> CastX2P node in address expression for unsafe memory operation
>> AddP(top, (CastX2P(SubI(3, loop_phi)), long) transformed into
>> AddP(top, ConP#3, SubI(0, loop_phi)):
>>
>> for (int idx = 0; idx < 4; idx++) {
>>  unsafe.putByte(bufptr + (3-idx), b);
>>
>> After loop full unroll this expression transformed
>> into AddP(top, ConP#3, -3). We hit assert during type
>> calculation for this node.
> 

(Continue reading)

Igor Veresov | 6 Jan 06:23 2011
Picon

Request for review(XS): 7010618: C1: array length should be treated at int on 64bit during array allocation

C1 needs to do sign-extension of array length during allocation.

Webrev: http://cr.openjdk.java.net/~iveresov/7010618/webrev.00/

Tested: failing nightly test

Tom Rodriguez | 6 Jan 07:18 2011
Picon

Re: Request for review(XS): 7010618: C1: array length should be treated at int on 64bit during array allocation

Looks good.

tom

On Jan 5, 2011, at 9:23 PM, Igor Veresov wrote:

> C1 needs to do sign-extension of array length during allocation.
> 
> Webrev: http://cr.openjdk.java.net/~iveresov/7010618/webrev.00/
> 
> Tested: failing nightly test

Vladimir Kozlov | 6 Jan 07:23 2011
Picon

Re: Request for review(XS): 7010618: C1: array length should be treated at int on 64bit during array allocation

Why you need it on x86?

Vladimir

On 1/5/11 9:23 PM, Igor Veresov wrote:
> C1 needs to do sign-extension of array length during allocation.
>
> Webrev: http://cr.openjdk.java.net/~iveresov/7010618/webrev.00/
>
> Tested: failing nightly test

Vladimir Kozlov | 6 Jan 07:40 2011
Picon

Re: Request for review(XS): 7010618: C1: array length should be treated at int on 64bit during array allocation

Never mind. Your changes are good.

Vladimir

On 1/5/11 10:23 PM, Vladimir Kozlov wrote:
> Why you need it on x86?
>
> Vladimir
>
> On 1/5/11 9:23 PM, Igor Veresov wrote:
>> C1 needs to do sign-extension of array length during allocation.
>>
>> Webrev: http://cr.openjdk.java.net/~iveresov/7010618/webrev.00/
>>
>> Tested: failing nightly test


Gmane