Webrev related to JavaCallArguments
duboscq at ssw.jku.at
Thu Aug 21 08:04:34 UTC 2014
I'm pushing this.
Regarding the test, i fixed a few variables shadowing issues
(warnings) in innerTest (res, cols, rows).
Also, any reason why the rows cols and loops fields are not static
final? It's not a performance issue but if they are just constants we
should probably make them fit the style we use for the rest of the
code (static final and capitalized).
On Wed, Aug 20, 2014 at 3:58 PM, Eric Caspole <eric.caspole at amd.com> wrote:
> Is this OK to be committed? This problem sometimes blocks other testing.
> On 08/11/2014 02:14 PM, Igor Veresov wrote:
>> Looks alright.
>> On Aug 11, 2014, at 6:01 AM, Caspole, Eric <Eric.Caspole at amd.com> wrote:
>>> Hi everybody,
>>> I put up a new webrev -
>>> 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.
>>> #5 report_vm_error (file=0x7ff50d10a2d8
>>> line=505, error_msg=0x7ff50d10a3e0 "guarantee(_is_oop[_pos++] == type)
>>> failed", detail_msg=0x7ff50d10a3b0 "signature does not match pushed
>>> arguments") at
>>> #6 0x00007ff50c9d49b2 in check_value (this=<optimized out>,
>>> type=<optimized out>) at
>>> #7 check_value (type=true, this=<optimized out>) at
>>> #8 check_obj (this=0x7ff50e307370, t=<optimized out>) at
>>> #9 SignatureChekker::do_array (this=0x7ff50e307370, begin=<optimized
>>> out>, end=<optimized out>) at
More information about the graal-dev