ARM: fix java.lang.Math.log10

[Xerxes Rånby]

2012-01-17 16:41, Andrew Haley skrev:
> On 01/17/2012 02:53 PM, Andrew Haley wrote:
>> On 01/17/2012 12:28 PM, Xerxes Rånby wrote:
> 
>>
>>> (oddity no 2)
>>> When installing vm_fatal_error as entry to handle the "java.dyn.MethodHandles::invoke" causes a signal 11
>>> I would have expected it to call report_should_not_reach_here and exit cleanly.
>>>
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> #  Internal Error (os_linux_zero.cpp:270), pid=11232, tid=1090544752
>>> #  fatal error: caught unhandled signal 11
>>
>> I'll fix that if you can provide a test case.
> 
> Fixed thusly.

Thanks!

> 
> Andrew.
> 

This patch are OK for icedtea6 head and icedtea6 1.11 release branch.

I have included a follow up patch to re-order some more register operands to silence warning for armv5 as well, see below.

> 
> 
> 2012-01-17  Andrew Haley  <aph at redhat.com>
> 
> 	* openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_arm.S
> 	(vm_fatal_error): Add an extra entry point at vm_fatal_error +
> 	CODE_ALIGN_SIZE to allow vm_fatal_error to be used as an entry
> 	point in asm_method_table.
> 
> 	(putstatic_volatile_dw): Re-order register operands to silence warning.
> 
> diff -r f57f03c70b52 arm_port/hotspot/src/cpu/zero/vm/cppInterpreter_arm.S
> --- a/arm_port/hotspot/src/cpu/zero/vm/cppInterpreter_arm.S	Mon Jan 16 13:28:17 2012 -0500
> +++ b/arm_port/hotspot/src/cpu/zero/vm/cppInterpreter_arm.S	Tue Jan 17 10:39:22 2012 -0500
> @@ -789,7 +789,9 @@
>  1:
>  	bx	lr
> 
> -// This table must be kept in sync with AbstractInterpreter::MethodKind
> +// This table must be kept in sync with
> +// AbstractInterpreter::MethodKind.  Note that every entry must have a
> +// corresponding fast entry point at addr + CODE_ALIGN_SIZE.
>  asm_method_table:
>  2:
>          .word   normal_entry                    // method needs locals initialization

ok

> @@ -2155,7 +2157,7 @@
>  putstatic_volatile_dw:
>  	DISPATCH_START	3
>  	add	ip, r2, r3
> -	POP	tmp1, tmp2
> +	POP	tmp2, tmp1
>  	DISPATCH_NEXT
>  	StoreStoreBarrier
>  #ifndef	__ARM_ARCH_7A__

I had to swap order for the stm instruction in the #ifndef __ARM_ARCH_7A__ as well to match this change, it fix and silence one more warning on non armv7 hosts.

Index: build/openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_arm.S
===================================================================
--- build.orig/openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_arm.S	2012-01-18 10:41:58.000000000 +0100
+++ build/openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_arm.S	2012-01-18 10:42:45.000000000 +0100
@@ -2161,7 +2161,7 @@
 	DISPATCH_NEXT
 	StoreStoreBarrier
 #ifndef	__ARM_ARCH_7A__
-	stm	ip, {tmp1, tmp2}
+	stm	ip, {tmp2, tmp1}
 #else
 	// Data in tmp1 & tmp2, address in ip, r2 & r3 scratch
 0:	ldrexd	r2, r3, [ip]



I have tried to verify if Volatile long operate correctly by running the Volatile tests from: http://www.cs.umd.edu/~pugh/java/memoryModel/ on armv5 and armv7.
Testcase: cd into icedtea build dir and execute
wget http://www.cs.umd.edu/~pugh/java/memoryModel/Volatiles.tar
tar xvf Volatiles.tar
./openjdk.build/j2sdk-image/bin/javac volatile/AtomicLong.java
./openjdk.build/j2sdk-image/bin/javac volatile/CoherenceVolatile.java
./openjdk.build/j2sdk-image/bin/javac volatile/ReadAfterWrite.java
./openjdk.build/j2sdk-image/bin/java -cp volatile AtomicLong
./openjdk.build/j2sdk-image/bin/java -cp volatile CoherenceVolatile
./openjdk.build/j2sdk-image/bin/java -cp volatile ReadAfterWrite

These tests pass, good, but a pass of these tests are still no guarantee that volatile longs work under all situations.
I really have no idea on how to reliably test volatile long operation.


> @@ -2519,6 +2521,7 @@
>  	CACHE_CP
>  	DISPATCH	1
> 
> +	ALIGN_CODE
>  vm_fatal_error:
>  	adr	r0, .fatal_filename
>  	mov	r1, #99
> @@ -2526,6 +2529,13 @@
>  	b	breakpoint
>  .fatal_filename:
>  	.ascii	"[Optimsed Assembler Interpreter Loop]\000"
> +
> +// This extra entry point for vm_fatal_error (at vm_fatal_error +
> +// CODE_ALIGN_SIZE) allows vm_fatal_error to be used as an entry point
> +// in the asm_method_table.
> +	ALIGN_CODE	
> +	b	vm_fatal_error
> +
>  	ALIGN_WORD
> 
>  	Opcode	aastore

ok

Cheers
Xerxes