harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-3731) [DRLVM] FinalizeStackTest failed in opt/srv mode on Win32
Date Tue, 24 Apr 2007 10:00:20 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491212
] 

Xiao-Feng Li commented on HARMONY-3731:
---------------------------------------


Good idea! And I don't think the performance overhead will be big with
this solution. ( The only thing is it is not a very precise exception.
But I think the preciseness can be improved by the catch handler to
compute the real mapping boundary from the trapped address, e.g., to
align it down to a page boundary, and to translate the position back
to jitted code and Java code. Well I don't think we really need this
preciseness. :-) )


Agree. SOE handling is not urgent. It's different from OOME, since
common  applications may not really want to catch the SOE for further
handling, but it's possible for them to deal with OOME. (In
traditional C program, I guess no one really want to handle stack
overflow, but it's common to test the return value of malloc.)




-- 
http://xiao-feng.blogspot.com


> [DRLVM] FinalizeStackTest failed in opt/srv mode on Win32
> ---------------------------------------------------------
>
>                 Key: HARMONY-3731
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3731
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Win32, opt/srv mode
>            Reporter: Xiao-Feng Li
>         Attachments: h3731.patch
>
>
> This test case breaks from time to time, but hard to be reproduced. We suggest to keep
it in JIRA and exclude it for opt/srv modes test.
> Pavel Afremov has following comments, which are helpful for people fixing the bug:
>   1. In this case, fast asm helpers aren't used, because allocation of
>   finalizable objects always goes throw slow path.
>   2. It will be very nice to found what returns 3 error code. Correct me
>   if I wrong, this code is returned when top level thread exception handler
>   catch unprocessed java exception. It's a different situation. When VM
>   crashed with unprocessed SOE in fast path asm helpers it returns 128 error
>   code.
>   3. It looks very strange that test works in client mode and doesn't
>   work in server. For VM side (exception handling and helpers) there is no
>   difference between these two modes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message