harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "weldon washburn (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-3627) [drlvm][exception] VM works incorrectly if several threads catch StackOverflowError
Date Sun, 24 Jun 2007 22:48:26 GMT

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

weldon washburn commented on HARMONY-3627:
------------------------------------------

Ilya's comments above, "...goes into VM/JIT code, and stack overflow occurs in native code
in non-unwindable area." leads us into an interesting area of JVM design.  In specific, how
to manage stack usage when executing vm internal native code.  This problem is somewhat similar
to app/kernel stack management in operating systems.  My opinion is that we do not have to
solve this problem at this time.  Its probably a 2008 kind of problem.  In any case, some
observations:

1)
Application code should never be able to use up basically all the stack, then do an OS call
and thus cause a crash inside Linux or Windows kernel.  This would make Denial Of Service
attacks very easy.  The same applies to a production JVM.
2)
The approach in OS design is to have a seperate kernel stack for each thread.  Its something
like 8KB in size.  The stack is toggled back and forth as the system toggles between user
and supervisor mode.  This guarantees a fixed amount of kernel stack regardless of what the
app is doing.  (It also prevents the app from snooping the kernel stack but this is a distraction
to the issue at hand.)

Somehow Harmony JVM needs to be designed to do something like the following in priority order:
1)
Guarantee there is enough stack for the JIT to do a compilation (or GC or whatever).  Maybe
do something like switch to a special jitting stack when space is tight.  Given that jitting/gc
takes a relatively long time, the cost of determining how much stack is available or even
finding special stack space should not be a big performance issue.
2)
If no additional stack space is available and this is a optimizing re-jit, simply skip the
compilation (the system continues to use the slow version -- graceful degradation).
3)
If jitting absolutely must be done and there is insufficient stack space, throw a StackOverflowError
(this is different than a StackOverflowException).

The first step in addressing the above is to do stack sizing for each of the major subcomponents.
 My guess is that the biggies are the JIT and GC.  Unless we have an interesting workload
that hits the above problems, its probabaly best to leave this design issue until later.




> [drlvm][exception] VM works incorrectly if several threads catch StackOverflowError
> -----------------------------------------------------------------------------------
>
>                 Key: HARMONY-3627
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3627
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>            Reporter: Vera Petrashkova
>            Priority: Minor
>
> When several threads expect  StackOverflowError then VM works incorrectly.
> The following test demonstrates this issue.
> VM crashes or finish its run abnormally.
> ----------------test.java-------------------
> public class test extends Thread {
>    public static void main (String[] argv) {
>         int N_TH = 5;
>         try {
>             if (argv.length > 0) {
>                 N_TH=Integer.parseInt(argv[0]);
>             }
>         } catch (Throwable e) {
>         }
>         test t[] = new test[N_TH];
>         for (int i = 0; i < N_TH; i++) {
>             t[i]=new test();
>             t[i].start();
>         }
>         try {
>             for (int i = 0; i < N_TH; i++) {
>                 t[i].join();
>             }
>         } catch (Throwable e) {
>             System.err.println(e);
>         }
>         System.out.println("Test passed");
>     }
>     public void m(int t) {
>              m(t+1);
>     }
>     public void run() {
>         System.err.println("Start");
>         try {
>             m(0);
>         } catch (StackOverflowError e) {
>         }
>     }
> }
> ------------------------------
> Run test
> java  -cp . test 20
> Output:
> Sometimes test passes.
> Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or
its l
> icensors, as applicable.
> java version "1.5.0"
> pre-alpha : not complete or compatible
> svn = r526746, (Apr 10 2007), Windows/ia32/msvc 1310, release build
> http://incubator.apache.org/harmony
> Start
> ...
> Start
> Test passed
> But  usually VM does not report full message and finishes execution or crashes:
> Start
> Start
> Start

-- 
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