Webrev related to JavaCallArguments
Igor Veresov
igor.veresov at oracle.com
Mon Aug 11 18:14:42 UTC 2014
Looks alright.
igor
On Aug 11, 2014, at 6:01 AM, Caspole, Eric <Eric.Caspole at amd.com> wrote:
> Hi everybody,
> I put up a new webrev -
>
> http://cr.openjdk.java.net/~ecaspole/long_java_args/
>
> It seems in the JavaCallArguments class there is some kind of assumption that there are less than 8 args when you call the default constructor.
> In this change I use the constructor that takes the args length to avoid the assert shown below, when there are more than 8 arguments. I included a new test that is usually successful to trigger the problem by having a longer running kernel with 9 arguments that notices a safepoint and would assert while handling the never-rans in the cleanup using the current code.
>
> Also in this webrev I snuck in a TraceTime around kernel generation, it is handy for us to see ow long this takes for various kernels.
>
> Thanks,
> Eric
>
> #5 report_vm_error (file=0x7ff50d10a2d8
> "/home/ecaspole/views/graal-sweep/graal/src/share/vm/runtime/javaCalls.cpp",
> line=505, error_msg=0x7ff50d10a3e0 "guarantee(_is_oop[_pos++] == type)
> failed", detail_msg=0x7ff50d10a3b0 "signature does not match pushed
> arguments") at
> /home/ecaspole/views/graal-sweep/graal/src/share/vm/utilities/debug.cpp:217
> #6 0x00007ff50c9d49b2 in check_value (this=<optimized out>,
> type=<optimized out>) at
> /home/ecaspole/views/graal-sweep/graal/src/share/vm/runtime/javaCalls.cpp:505
> #7 check_value (type=true, this=<optimized out>) at
> /home/ecaspole/views/graal-sweep/graal/src/share/vm/runtime/javaCalls.cpp:570
> #8 check_obj (this=0x7ff50e307370, t=<optimized out>) at
> /home/ecaspole/views/graal-sweep/graal/src/share/vm/runtime/javaCalls.cpp:557
> #9 SignatureChekker::do_array (this=0x7ff50e307370, begin=<optimized
> out>, end=<optimized out>) at
> /home/ecaspole/views/graal-sweep/graal/src/share/vm/runtime/javaCalls.cpp:570
More information about the graal-dev
mailing list