Discussion:
RFR(S): 8050022: linux-sparcv9: assert(SharedSkipVerify || obj->is_oop()) failed: sanity check
(too old to reply)
Morris Meyer
2014-09-10 15:00:06 UTC
Permalink
Folks,

Could I get a review for this issue? On Linux-SPARC, in the
jnistress002 test, the registers all save cleanly, and the JNI call into
jniobjects() happens cleanly. Inside the compiled JNI method, prior to
the first (*env)->MonitorEnter(), the code spills the float and double
arguments onto the stack, which happens to corrupt both JNIEnv *env, and
jobject jobj.

JNIEXPORT jobjectArray JNICALL
Java_nsk_stress_jni_JNIStress002_JNIter_jniobjects (JNIEnv *env, jobject
jobj, jstring jstr, jint intgr,
jlong lng, jcharArray jChArr, jfloat flt, jdouble dbl) {

static int classCount = 0;
jobjectArray obj;
jobject element;
jclass clazz, clazzUp;
jmethodID methodID;
jfieldID classNoID;
const char *classname="nsk/stress/jni/JNIStress002/objectsJNI";
const char *name="<init>";
const char *sig="(Ljava/lang/String;IJ[CFD)V";
const char *upperClassName="nsk/stress/jni/JNIStress002/jnistress002";
const char *fieldName="jniStringAllocSize";
const char *fieldSig="I";
const char *setpass="halt";
const char *setpassSig="()V";
jvalue paramArr [6];
int kkk;

(*env)->MonitorEnter(env, jobj); CE

The fix is to allocate stack spillage space for Linux SPARC machines for
floating point arguments passed as registers. I didn't touch the V8
side of this as I'm not sure if we even have a V8 machine (pre-2000)
running Linux.

Tested with JPRT and nsk.stress.

--morris

WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.01/
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
David Chase
2014-09-10 15:16:21 UTC
Permalink
(Not a Reviewer review)

Style question ? in the stack-slot manipulating code in
src/cpu/sparc/vm/sharedRuntime_sparc.cpp, it says
// V9ism: floats go in ODD registers
and then repeats this expression three times
1 + (j << 1)
Perhaps it would be better to say (after the comment)
int float_index = 1 + (j << 1);
and repeat float_index three times,
and likewise for the even index in the double case
int double_index = (j<<1)

Other than that, I like it, especially the typos/spellos that you caught in associated files.

David
Post by Morris Meyer
Folks,
Could I get a review for this issue? On Linux-SPARC, in the jnistress002 test, the registers all save cleanly, and the JNI call into jniobjects() happens cleanly. Inside the compiled JNI method, prior to the first (*env)->MonitorEnter(), the code spills the float and double arguments onto the stack, which happens to corrupt both JNIEnv *env, and jobject jobj.
JNIEXPORT jobjectArray JNICALL
Java_nsk_stress_jni_JNIStress002_JNIter_jniobjects (JNIEnv *env, jobject jobj, jstring jstr, jint intgr,
jlong lng, jcharArray jChArr, jfloat flt, jdouble dbl) {
static int classCount = 0;
jobjectArray obj;
jobject element;
jclass clazz, clazzUp;
jmethodID methodID;
jfieldID classNoID;
const char *classname="nsk/stress/jni/JNIStress002/objectsJNI";
const char *name="<init>";
const char *sig="(Ljava/lang/String;IJ[CFD)V";
const char *upperClassName="nsk/stress/jni/JNIStress002/jnistress002";
const char *fieldName="jniStringAllocSize";
const char *fieldSig="I";
const char *setpass="halt";
const char *setpassSig="()V";
jvalue paramArr [6];
int kkk;
(*env)->MonitorEnter(env, jobj); CE
The fix is to allocate stack spillage space for Linux SPARC machines for floating point arguments passed as registers. I didn't touch the V8 side of this as I'm not sure if we even have a V8 machine (pre-2000) running Linux.
Tested with JPRT and nsk.stress.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.01/
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140910/1ec376a7/signature.asc>
John Rose
2014-09-10 19:18:02 UTC
Permalink
Post by David Chase
Perhaps it would be better to say (after the comment)
int float_index = 1 + (j << 1);
and repeat float_index three times,
and likewise for the even index in the double case
int double_index = (j<<1)
I agree with that point.
Post by David Chase
Other than that, I like it, especially the typos/spellos that you caught in associated files.
+1

Style comment: The name "_sp_adjustment_floating_point" should be "_floating_point_sp_adjustment" to match HotSpot's local pattern for C++ accessors. Also, since it is a boolean, the accessor should sound like a boolean (not an "adjustment"), like "adjust_sp_for_floating_point".

But, I have a bigger issue which make make that moot: The "adjust_sp_for_floating_point" dance is awkward but acceptable (maybe with amendments) if it is truly a system-specific issue. I don't think it is system-specific, but ABI-specific. What does the ABI documentation say about this case?

I googled to http://www.sparc.org/technical-documents-test-2/specifications/ and then to http://www.sparc.org/wp-content/uploads/2014/01/SCD.2.4.1.pdf.gz .
Post by David Chase
When a callee prototype exists, and does not indicate variable arguments, floating- point values assigned to locations %sp+BIAS+128 through %sp+BIAS+248 will be promoted into floating-point registers, as shown above.
By "promoted" it means that the argument is located in two places, an unused spill slot in the "parameter array" (starts at %sp+BIAS+128), and a live float register. In most cases, there are 6 or fewer arguments of any type, and the standard parameter array slots (%sp+BIAS+128 to %sp+BIAS+176 exclusive) serve as shadow slots. But floating point registers %d6 to %d16 require slots beyond that (up to %sp+BIAS+248, as the spec. says).

This means that the whole adjust_sp_for_floating_point dance should go away, and the parameter array extension needs to be done on all LP64 sparc systems.

Sparc does it this way in order to have a very simple varargs implementation (one contiguous parameter array, allocated by the caller). If there are other systems which have a similar C ABI, we will have a similar bug for those also. Would you mind looking at the corresponding code for other cpus we support, and seeing if there is potentially the same bug there also? If so we can check the relevant ABI docs and perhaps file bugs for those guys also.

Thanks!

? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140910/c8f21580/attachment-0001.html>
Morris Meyer
2014-09-12 21:16:21 UTC
Permalink
Folks,

Upon further inspection John and I looked at the SPARC ABI - and the ARM
and PPC ABIs as well.

We are applying the stack promotion for floating point registers to both
LInux and Solaris for the SPARC ABI. I will file two P4 bugs to look
into this issue on 32-bit ARM and PPC. John looked into ARMv8 here
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf)
and found on that chip the callee allocates the argument dump area, so
the SPARC problem is not present.

Here is my latest rev, which has been tested on the original machine
(slc08gjo.us.oracle.com) and with JPRT. I also tested this fix against
8043892 which also works now. I closed 8043892 as a duplicate of 8050022.

--morris

WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.02
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
Vladimir Kozlov
2014-09-12 23:25:50 UTC
Permalink
Changes look good. Thank you for nice comments.

Thanks,
Vladimir
Post by Morris Meyer
Folks,
Upon further inspection John and I looked at the SPARC ABI - and the ARM and PPC ABIs as well.
We are applying the stack promotion for floating point registers to both LInux and Solaris for the SPARC ABI. I will
file two P4 bugs to look into this issue on 32-bit ARM and PPC. John looked into ARMv8 here
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf) and found on that chip the callee
allocates the argument dump area, so the SPARC problem is not present.
Here is my latest rev, which has been tested on the original machine (slc08gjo.us.oracle.com) and with JPRT. I also
tested this fix against 8043892 which also works now. I closed 8043892 as a duplicate of 8050022.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.02
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
Morris Meyer
2014-09-13 18:26:03 UTC
Permalink
Thanks Vladimir!

Sorry to drag you through another review, but John had a further cleanup
to make things a little more readable.

I've tested this and 8043892 on the original machine
(slc08gjo.us.oracle.com) and with JPRT.

--morris

WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.03/
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
Post by Vladimir Kozlov
Changes look good. Thank you for nice comments.
Thanks,
Vladimir
Post by Morris Meyer
Folks,
Upon further inspection John and I looked at the SPARC ABI - and the
ARM and PPC ABIs as well.
We are applying the stack promotion for floating point registers to
both LInux and Solaris for the SPARC ABI. I will
file two P4 bugs to look into this issue on 32-bit ARM and PPC. John
looked into ARMv8 here
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf)
and found on that chip the callee
allocates the argument dump area, so the SPARC problem is not present.
Here is my latest rev, which has been tested on the original machine
(slc08gjo.us.oracle.com) and with JPRT. I also
tested this fix against 8043892 which also works now. I closed
8043892 as a duplicate of 8050022.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.02
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
Vladimir Kozlov
2014-09-15 18:24:06 UTC
Permalink
Why you defined 'int fpu_index' outside of loop. It is used only in local scopes. And don't separate it from use place
by comment. Your previous webrev had it right.

Otherwise it looks good.

Thanks,
Vladimir
Post by Morris Meyer
Thanks Vladimir!
Sorry to drag you through another review, but John had a further cleanup to make things a little more readable.
I've tested this and 8043892 on the original machine (slc08gjo.us.oracle.com) and with JPRT.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.03/
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
Post by Vladimir Kozlov
Changes look good. Thank you for nice comments.
Thanks,
Vladimir
Post by Morris Meyer
Folks,
Upon further inspection John and I looked at the SPARC ABI - and the ARM and PPC ABIs as well.
We are applying the stack promotion for floating point registers to both LInux and Solaris for the SPARC ABI. I will
file two P4 bugs to look into this issue on 32-bit ARM and PPC. John looked into ARMv8 here
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf) and found on that chip the callee
allocates the argument dump area, so the SPARC problem is not present.
Here is my latest rev, which has been tested on the original machine (slc08gjo.us.oracle.com) and with JPRT. I also
tested this fix against 8043892 which also works now. I closed 8043892 as a duplicate of 8050022.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.02
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
Morris Meyer
2014-09-15 19:33:49 UTC
Permalink
Thanks for the review. Here's the webrev that addresses that issue.

--morris

WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.04
Post by Vladimir Kozlov
Why you defined 'int fpu_index' outside of loop. It is used only in
local scopes. And don't separate it from use place by comment. Your
previous webrev had it right.
Otherwise it looks good.
Thanks,
Vladimir
Post by Morris Meyer
Thanks Vladimir!
Sorry to drag you through another review, but John had a further
cleanup to make things a little more readable.
I've tested this and 8043892 on the original machine
(slc08gjo.us.oracle.com) and with JPRT.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.03/
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
Post by Vladimir Kozlov
Changes look good. Thank you for nice comments.
Thanks,
Vladimir
Post by Morris Meyer
Folks,
Upon further inspection John and I looked at the SPARC ABI - and
the ARM and PPC ABIs as well.
We are applying the stack promotion for floating point registers to
both LInux and Solaris for the SPARC ABI. I will
file two P4 bugs to look into this issue on 32-bit ARM and PPC.
John looked into ARMv8 here
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf)
and found on that chip the callee
allocates the argument dump area, so the SPARC problem is not present.
Here is my latest rev, which has been tested on the original
machine (slc08gjo.us.oracle.com) and with JPRT. I also
tested this fix against 8043892 which also works now. I closed
8043892 as a duplicate of 8050022.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.02
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
Vladimir Kozlov
2014-09-15 19:46:02 UTC
Permalink
What about "And don't separate it from use place by comment"? At line 1165.

Vladimir
Post by Morris Meyer
Thanks for the review. Here's the webrev that addresses that issue.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.04
Post by Vladimir Kozlov
Why you defined 'int fpu_index' outside of loop. It is used only in
local scopes. And don't separate it from use place by comment. Your
previous webrev had it right.
Otherwise it looks good.
Thanks,
Vladimir
Post by Morris Meyer
Thanks Vladimir!
Sorry to drag you through another review, but John had a further
cleanup to make things a little more readable.
I've tested this and 8043892 on the original machine
(slc08gjo.us.oracle.com) and with JPRT.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.03/
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
Post by Vladimir Kozlov
Changes look good. Thank you for nice comments.
Thanks,
Vladimir
Post by Morris Meyer
Folks,
Upon further inspection John and I looked at the SPARC ABI - and
the ARM and PPC ABIs as well.
We are applying the stack promotion for floating point registers to
both LInux and Solaris for the SPARC ABI. I will
file two P4 bugs to look into this issue on 32-bit ARM and PPC.
John looked into ARMv8 here
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf)
and found on that chip the callee
allocates the argument dump area, so the SPARC problem is not present.
Here is my latest rev, which has been tested on the original
machine (slc08gjo.us.oracle.com) and with JPRT. I also
tested this fix against 8043892 which also works now. I closed
8043892 as a duplicate of 8050022.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.02
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
John Rose
2014-09-15 19:56:27 UTC
Permalink
Why you defined 'int fpu_index' outside of loop. It is used only in local scopes. And don't separate it from use place by comment. Your previous webrev had it right.
But the previous webrev didn't catch all uses of the common sub-expression.
Plus, the temp is used in two cases of the switch.
Would you prefer to introduce the temp twice, one per case?
That will also require putting brackets around each case, to introduce a block scope.
Otherwise it looks good.
Thanks,
Vladimir
Post by Morris Meyer
Thanks Vladimir!
Sorry to drag you through another review, but John had a further cleanup to make things a little more readable.
I've tested this and 8043892 on the original machine (slc08gjo.us.oracle.com) and with JPRT.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.03/
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
Post by Vladimir Kozlov
Changes look good. Thank you for nice comments.
Thanks,
Vladimir
Post by Morris Meyer
Folks,
Upon further inspection John and I looked at the SPARC ABI - and the ARM and PPC ABIs as well.
We are applying the stack promotion for floating point registers to both LInux and Solaris for the SPARC ABI. I will
file two P4 bugs to look into this issue on 32-bit ARM and PPC. John looked into ARMv8 here
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf) and found on that chip the callee
allocates the argument dump area, so the SPARC problem is not present.
Here is my latest rev, which has been tested on the original machine (slc08gjo.us.oracle.com) and with JPRT. I also
tested this fix against 8043892 which also works now. I closed 8043892 as a duplicate of 8050022.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.02
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
Vladimir Kozlov
2014-09-15 20:08:59 UTC
Permalink
We are compiler guys :) We should help C++ compiler too. Why increase
live range of a value when it is not needed?
Post by John Rose
Why you defined 'int fpu_index' outside of loop. It is used only in local scopes. And don't separate it from use place by comment. Your previous webrev had it right.
But the previous webrev didn't catch all uses of the common sub-expression.
I am complaining only about 'double_index'.
Post by John Rose
Plus, the temp is used in two cases of the switch.
Would you prefer to introduce the temp twice, one per case?
Yes, that is what I want for 'double_index'.
Post by John Rose
That will also require putting brackets around each case, to introduce a block scope.
Yes, we need parenthesis too. It is better to have explicit scope anyway.

Vladimir
Post by John Rose
Otherwise it looks good.
Thanks,
Vladimir
Post by Morris Meyer
Thanks Vladimir!
Sorry to drag you through another review, but John had a further cleanup to make things a little more readable.
I've tested this and 8043892 on the original machine (slc08gjo.us.oracle.com) and with JPRT.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.03/
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
Post by Vladimir Kozlov
Changes look good. Thank you for nice comments.
Thanks,
Vladimir
Post by Morris Meyer
Folks,
Upon further inspection John and I looked at the SPARC ABI - and the ARM and PPC ABIs as well.
We are applying the stack promotion for floating point registers to both LInux and Solaris for the SPARC ABI. I will
file two P4 bugs to look into this issue on 32-bit ARM and PPC. John looked into ARMv8 here
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf) and found on that chip the callee
allocates the argument dump area, so the SPARC problem is not present.
Here is my latest rev, which has been tested on the original machine (slc08gjo.us.oracle.com) and with JPRT. I also
tested this fix against 8043892 which also works now. I closed 8043892 as a duplicate of 8050022.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.02
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
John Rose
2014-09-15 20:33:06 UTC
Permalink
Post by Vladimir Kozlov
Post by John Rose
Plus, the temp is used in two cases of the switch.
Would you prefer to introduce the temp twice, one per case?
Yes, that is what I want for 'double_index'.
Post by John Rose
That will also require putting brackets around each case, to introduce a block scope.
Yes, we need parenthesis too. It is better to have explicit scope anyway.
OK, that's fair.

? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140915/73396e1f/attachment.html>
Morris Meyer
2014-09-15 23:25:18 UTC
Permalink
Ok. Here is the latest version. Thanks for the reviews.

--morris

WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.05
Post by Vladimir Kozlov
We are compiler guys :) We should help C++ compiler too. Why increase
live range of a value when it is not needed?
On Sep 15, 2014, at 11:24 AM, Vladimir Kozlov
Post by Vladimir Kozlov
Why you defined 'int fpu_index' outside of loop. It is used only in
local scopes. And don't separate it from use place by comment. Your
previous webrev had it right.
But the previous webrev didn't catch all uses of the common
sub-expression.
I am complaining only about 'double_index'.
Plus, the temp is used in two cases of the switch.
Would you prefer to introduce the temp twice, one per case?
Yes, that is what I want for 'double_index'.
That will also require putting brackets around each case, to
introduce a block scope.
Yes, we need parenthesis too. It is better to have explicit scope anyway.
Vladimir
Post by Vladimir Kozlov
Otherwise it looks good.
Thanks,
Vladimir
Post by Morris Meyer
Thanks Vladimir!
Sorry to drag you through another review, but John had a further
cleanup to make things a little more readable.
I've tested this and 8043892 on the original machine
(slc08gjo.us.oracle.com) and with JPRT.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.03/
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
Post by Vladimir Kozlov
Changes look good. Thank you for nice comments.
Thanks,
Vladimir
Post by Morris Meyer
Folks,
Upon further inspection John and I looked at the SPARC ABI - and
the ARM and PPC ABIs as well.
We are applying the stack promotion for floating point registers
to both LInux and Solaris for the SPARC ABI. I will
file two P4 bugs to look into this issue on 32-bit ARM and PPC.
John looked into ARMv8 here
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf)
and found on that chip the callee
allocates the argument dump area, so the SPARC problem is not present.
Here is my latest rev, which has been tested on the original
machine (slc08gjo.us.oracle.com) and with JPRT. I also
tested this fix against 8043892 which also works now. I closed
8043892 as a duplicate of 8050022.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.02
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
Vladimir Kozlov
2014-09-16 00:22:04 UTC
Permalink
Good.

Thanks,
Vladimir
Post by Morris Meyer
Ok. Here is the latest version. Thanks for the reviews.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.05
Post by Vladimir Kozlov
We are compiler guys :) We should help C++ compiler too. Why increase
live range of a value when it is not needed?
On Sep 15, 2014, at 11:24 AM, Vladimir Kozlov
Post by Vladimir Kozlov
Why you defined 'int fpu_index' outside of loop. It is used only in
local scopes. And don't separate it from use place by comment. Your
previous webrev had it right.
But the previous webrev didn't catch all uses of the common
sub-expression.
I am complaining only about 'double_index'.
Plus, the temp is used in two cases of the switch.
Would you prefer to introduce the temp twice, one per case?
Yes, that is what I want for 'double_index'.
That will also require putting brackets around each case, to
introduce a block scope.
Yes, we need parenthesis too. It is better to have explicit scope anyway.
Vladimir
Post by Vladimir Kozlov
Otherwise it looks good.
Thanks,
Vladimir
Post by Morris Meyer
Thanks Vladimir!
Sorry to drag you through another review, but John had a further
cleanup to make things a little more readable.
I've tested this and 8043892 on the original machine
(slc08gjo.us.oracle.com) and with JPRT.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.03/
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
Post by Vladimir Kozlov
Changes look good. Thank you for nice comments.
Thanks,
Vladimir
Post by Morris Meyer
Folks,
Upon further inspection John and I looked at the SPARC ABI - and
the ARM and PPC ABIs as well.
We are applying the stack promotion for floating point registers
to both LInux and Solaris for the SPARC ABI. I will
file two P4 bugs to look into this issue on 32-bit ARM and PPC.
John looked into ARMv8 here
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf)
and found on that chip the callee
allocates the argument dump area, so the SPARC problem is not present.
Here is my latest rev, which has been tested on the original
machine (slc08gjo.us.oracle.com) and with JPRT. I also
tested this fix against 8043892 which also works now. I closed
8043892 as a duplicate of 8050022.
--morris
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8050022.02
JBS - https://bugs.openjdk.java.net/browse/JDK-8050022
Loading...