sablevm-bugs Mailing List for SableVM (Page 4)
Brought to you by:
egagnon
Menu
▾
▴
sablevm-bugs — SableVM bugs mailing list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(4) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(16) |
Sep
(10) |
Oct
|
Nov
(2) |
Dec
(7) |
| 2003 |
Jan
(14) |
Feb
(11) |
Mar
(59) |
Apr
(3) |
May
(1) |
Jun
(7) |
Jul
(8) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
(26) |
Apr
|
May
|
Jun
(1) |
Jul
(12) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2003-03-18 20:46:28
|
Bugs item #705868, was opened at 2003-03-18 15:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=705868&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Chris Pickett (cpickett) Assigned to: Nobody/Anonymous (nobody) Summary: multiprocessor crashes Initial Comment: SableVM still segfaults on a multiprocessor, even with fixes for yield() and _svmf_set_current_env(). However, now execution completes 50% of the time. Attached are parallel and non-parallel matrix multiply benchmarks. For non-parallel: java matmul N where N is the size of matrix and for parallel: java matmul_p N P where P is the number of processors. There are no problems on uniprocessors. Cheers, Chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=705868&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-18 16:30:54
|
Bugs item #704533, was opened at 2003-03-16 10:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704533&group_id=5523 Category: Wishlist Group: SableVM Status: Open Resolution: None Priority: 2 Submitted By: Chris Pickett (ihatemcgill) Assigned to: Etienne M. Gagnon (egagnon) Summary: types should end in _t for better syntax highlighting Initial Comment: Change _svmt_* to _svmt_*_t for better syntax highlighting in all C files. It really is *much* more readable, even if there's an extra "_t". ---------------------------------------------------------------------- Comment By: Chris Pickett (cpickett) Date: 2003-03-18 11:42 Message: Logged In: YES user_id=715646 Or, as David suggested, figure out how to change emacs syntax coloring. Personally, this is a better solution, because then things like jint, jvalue, etc. can get colored. Cheers, Chris ---------------------------------------------------------------------- Comment By: Chris Pickett (cpickett) Date: 2003-03-16 14:40 Message: Logged In: YES user_id=715646 in libsablevm: emacs RET M-x dired RET RET % m ^[_a-zA-Z0-9]*\.[_a-zA-Z0-9\.]*$ RET Q _svmt_[_a-zA-Z0-9\$]* RET \&_t RET ! -----> hold down the key until finished. now in jnidefs.h and types.h M-x replace-string RET struct_t RET struct RET C-x C-s RET y RET .............. that should be it. probably want to repeat the same thing in libsablevm/include -- emacs lets you scroll through a history of commands using the up arrow, or you can just cut and paste from this message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704533&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 19:28:20
|
Bugs item #704533, was opened at 2003-03-16 10:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704533&group_id=5523 Category: Wishlist Group: SableVM Status: Open Resolution: None Priority: 2 Submitted By: Chris Pickett (ihatemcgill) Assigned to: Etienne M. Gagnon (egagnon) Summary: types should end in _t for better syntax highlighting Initial Comment: Change _svmt_* to _svmt_*_t for better syntax highlighting in all C files. It really is *much* more readable, even if there's an extra "_t". ---------------------------------------------------------------------- Comment By: Chris Pickett (cpickett) Date: 2003-03-16 14:40 Message: Logged In: YES user_id=715646 in libsablevm: emacs RET M-x dired RET RET % m ^[_a-zA-Z0-9]*\.[_a-zA-Z0-9\.]*$ RET Q _svmt_[_a-zA-Z0-9\$]* RET \&_t RET ! -----> hold down the key until finished. now in jnidefs.h and types.h M-x replace-string RET struct_t RET struct RET C-x C-s RET y RET .............. that should be it. probably want to repeat the same thing in libsablevm/include -- emacs lets you scroll through a history of commands using the up arrow, or you can just cut and paste from this message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704533&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 16:42:29
|
Bugs item #704526, was opened at 2003-03-16 10:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704526&group_id=5523 Category: Whishlist Group: SableVM Status: Open Resolution: None Priority: 2 Submitted By: Chris Pickett (ihatemcgill) Assigned to: Etienne M. Gagnon (egagnon) Summary: bytecode numbering Initial Comment: Hi, The instructions in constants.h correspond to the JVM spec bytecode numbering up until 201, after which point all instructions are SableVM-specific instructions. Is this ordering used to parse class files? If so, then the SableVM-specific instructions should start at 256. There are two reasons: 1) Sun may expand the bytecode set in the future, at which point it will be necessary to renumber things anyway. 2) I would like to use the "impdep1" and possibly "impdep2" opcodes, which have numbers 254 and 255. I want to transform a class file to have impdep1 / impdep2 opcodes using Soot, and so if this same ordering is really the ordering used to parse class files (I think it is), then I need those spots to be free. Currently, I am redefining PUTFIELD_INT and PUTFIELD_LONG from 254 and 255 to 333 and 334 respectively, but it is cleaner if everything is shifted down to start at 256. If this change is okay, I can make a patch with the renumbered instructions. Cheers, Chris ---------------------------------------------------------------------- >Comment By: Chris Pickett (ihatemcgill) Date: 2003-03-16 11:54 Message: Logged In: YES user_id=630752 Okay, I can do that. However, I still think the constants should be renumbered. I was going to use impdep1 to fork a speculative thread, with an address of the bytecode at which to start the execution. So, if I used attributes, I would pass the locations in the code array at which to insert SableVM-only bytecodes to the VM, and then they would get inserted during code preparation. This way, there are an unlimited number of bytecodes I can play with (although I think I only need two). I just thought it would be easier to get things working with the impdep1/impdep2 bytecodes. ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2003-03-16 11:21 Message: Logged In: YES user_id=15365 Be warned that the official SableVM source base will not deviate from the JVM specification by accepting bytecodes other than those specified by the JVM specification. You should consider using attributes, instead, as custom attributes are supported by the JVM specification, and probably allow you to achieve your goal of communicating extra information to the VM. One big advantage of the attribute approach is that your class files remain executable under other JVMs, which is a good thing to detect any invalid bytecode sequence Soot might generate (by running the class under a JVM with a bytecode verifier). Etienne ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704526&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 16:28:43
|
Bugs item #704531, was opened at 2003-03-16 10:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704531&group_id=5523 Category: Other Group: SableVM Status: Closed Resolution: Rejected Priority: 1 Submitted By: Chris Pickett (ihatemcgill) Assigned to: Etienne M. Gagnon (egagnon) Summary: super and synchronized access flags are identical Initial Comment: From constants.h: /* access flags */ #define SVM_ACC_PUBLIC 0x0001 #define SVM_ACC_PRIVATE 0x0002 #define SVM_ACC_PROTECTED 0x0004 #define SVM_ACC_STATIC 0x0008 #define SVM_ACC_FINAL 0x0010 #define SVM_ACC_SUPER 0x0020 #define SVM_ACC_SYNCHRONIZED 0x0020 #define SVM_ACC_VOLATILE 0x0040 #define SVM_ACC_TRANSIENT 0x0080 #define SVM_ACC_NATIVE 0x0100 #define SVM_ACC_INTERFACE 0x0200 #define SVM_ACC_ABSTRACT 0x0400 #define SVM_ACC_STRICT 0x0800 #define SVM_ACC_INTERNAL 0x1000 ---------------------------------------------------------------------- >Comment By: Chris Pickett (ihatemcgill) Date: 2003-03-16 11:40 Message: Logged In: YES user_id=630752 sorry, I thought they were SableVM specific and there was a typo. ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2003-03-16 11:09 Message: Logged In: YES user_id=15365 In the JVM specification [4.6 Methods] you can read: ACC_SYNCHRONIZED 0x0020 Declared synchronized; invocation is wrapped in a monitor lock. ---------------------------------------------------------------------- Comment By: Chris Pickett (ihatemcgill) Date: 2003-03-16 10:55 Message: Logged In: YES user_id=630752 /* access flags */ #define SVM_ACC_PUBLIC 0x0001 #define SVM_ACC_PRIVATE 0x0002 #define SVM_ACC_PROTECTED 0x0004 #define SVM_ACC_STATIC 0x0008 #define SVM_ACC_FINAL 0x0010 #define SVM_ACC_SUPER 0x0020 #define SVM_ACC_SYNCHRONIZED 0x0040 #define SVM_ACC_VOLATILE 0x0080 #define SVM_ACC_TRANSIENT 0x0100 #define SVM_ACC_NATIVE 0x0200 #define SVM_ACC_INTERFACE 0x0400 #define SVM_ACC_ABSTRACT 0x0800 #define SVM_ACC_STRICT 0x1000 #define SVM_ACC_INTERNAL 0x2000 is fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704531&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 16:11:54
|
Bugs item #704345, was opened at 2003-03-15 20:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704345&group_id=5523 >Category: Whishlist Group: SableVM Status: Open Resolution: None Priority: 1 Submitted By: Chris Pickett (ihatemcgill) Assigned to: Nobody/Anonymous (nobody) Summary: optimization of method preparation Initial Comment: In Ch.2 of his thesis, Etienne explains the code preparation technique to replace slow instructions that must check for class initialization with faster ones (patching in code from the end of the code array at runtime). However, once a class is initialized, then for future preparation of methods that use this class, it is unnecessary to have either the slow version or the patch. The only cost of this optimization is an extra check at method preparation time for each instruction that requires class initialization, to see if the class has already been initialized. The savings are that 1) neither patching code nor slow initialization code needs to be prepared 2) there is no patching that ever takes place for that instruction and 3) (most importantly), we save at least one synchronization on the slow initialization instruction. This optimization is applicable to all three threading modes, but it will of course be most interesting to see if it improves inlined-threading. ---------------------------------------------------------------------- >Comment By: Etienne M. Gagnon (egagnon) Date: 2003-03-16 11:24 Message: Logged In: YES user_id=15365 Hi Chris, You are highly encouraged to submit a patch as attachment to this bug. :-) Etienne ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704345&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 16:08:53
|
Bugs item #704526, was opened at 2003-03-16 10:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704526&group_id=5523 >Category: Whishlist >Group: SableVM Status: Open Resolution: None >Priority: 2 Submitted By: Chris Pickett (ihatemcgill) >Assigned to: Etienne M. Gagnon (egagnon) Summary: bytecode numbering Initial Comment: Hi, The instructions in constants.h correspond to the JVM spec bytecode numbering up until 201, after which point all instructions are SableVM-specific instructions. Is this ordering used to parse class files? If so, then the SableVM-specific instructions should start at 256. There are two reasons: 1) Sun may expand the bytecode set in the future, at which point it will be necessary to renumber things anyway. 2) I would like to use the "impdep1" and possibly "impdep2" opcodes, which have numbers 254 and 255. I want to transform a class file to have impdep1 / impdep2 opcodes using Soot, and so if this same ordering is really the ordering used to parse class files (I think it is), then I need those spots to be free. Currently, I am redefining PUTFIELD_INT and PUTFIELD_LONG from 254 and 255 to 333 and 334 respectively, but it is cleaner if everything is shifted down to start at 256. If this change is okay, I can make a patch with the renumbered instructions. Cheers, Chris ---------------------------------------------------------------------- >Comment By: Etienne M. Gagnon (egagnon) Date: 2003-03-16 11:21 Message: Logged In: YES user_id=15365 Be warned that the official SableVM source base will not deviate from the JVM specification by accepting bytecodes other than those specified by the JVM specification. You should consider using attributes, instead, as custom attributes are supported by the JVM specification, and probably allow you to achieve your goal of communicating extra information to the VM. One big advantage of the attribute approach is that your class files remain executable under other JVMs, which is a good thing to detect any invalid bytecode sequence Soot might generate (by running the class under a JVM with a bytecode verifier). Etienne ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704526&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 16:04:15
|
Bugs item #704533, was opened at 2003-03-16 10:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704533&group_id=5523 >Category: Whishlist Group: SableVM Status: Open Resolution: None >Priority: 2 Submitted By: Chris Pickett (ihatemcgill) >Assigned to: Etienne M. Gagnon (egagnon) Summary: types should end in _t for better syntax highlighting Initial Comment: Change _svmt_* to _svmt_*_t for better syntax highlighting in all C files. It really is *much* more readable, even if there's an extra "_t". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704533&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 15:58:28
|
Bugs item #704531, was opened at 2003-03-16 10:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704531&group_id=5523 Category: Other Group: SableVM Status: Closed Resolution: Rejected >Priority: 1 Submitted By: Chris Pickett (ihatemcgill) Assigned to: Etienne M. Gagnon (egagnon) Summary: super and synchronized access flags are identical Initial Comment: From constants.h: /* access flags */ #define SVM_ACC_PUBLIC 0x0001 #define SVM_ACC_PRIVATE 0x0002 #define SVM_ACC_PROTECTED 0x0004 #define SVM_ACC_STATIC 0x0008 #define SVM_ACC_FINAL 0x0010 #define SVM_ACC_SUPER 0x0020 #define SVM_ACC_SYNCHRONIZED 0x0020 #define SVM_ACC_VOLATILE 0x0040 #define SVM_ACC_TRANSIENT 0x0080 #define SVM_ACC_NATIVE 0x0100 #define SVM_ACC_INTERFACE 0x0200 #define SVM_ACC_ABSTRACT 0x0400 #define SVM_ACC_STRICT 0x0800 #define SVM_ACC_INTERNAL 0x1000 ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2003-03-16 11:09 Message: Logged In: YES user_id=15365 In the JVM specification [4.6 Methods] you can read: ACC_SYNCHRONIZED 0x0020 Declared synchronized; invocation is wrapped in a monitor lock. ---------------------------------------------------------------------- Comment By: Chris Pickett (ihatemcgill) Date: 2003-03-16 10:55 Message: Logged In: YES user_id=630752 /* access flags */ #define SVM_ACC_PUBLIC 0x0001 #define SVM_ACC_PRIVATE 0x0002 #define SVM_ACC_PROTECTED 0x0004 #define SVM_ACC_STATIC 0x0008 #define SVM_ACC_FINAL 0x0010 #define SVM_ACC_SUPER 0x0020 #define SVM_ACC_SYNCHRONIZED 0x0040 #define SVM_ACC_VOLATILE 0x0080 #define SVM_ACC_TRANSIENT 0x0100 #define SVM_ACC_NATIVE 0x0200 #define SVM_ACC_INTERFACE 0x0400 #define SVM_ACC_ABSTRACT 0x0800 #define SVM_ACC_STRICT 0x1000 #define SVM_ACC_INTERNAL 0x2000 is fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704531&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 15:57:17
|
Bugs item #704531, was opened at 2003-03-16 10:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704531&group_id=5523 Category: Other Group: SableVM >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Chris Pickett (ihatemcgill) >Assigned to: Etienne M. Gagnon (egagnon) Summary: super and synchronized access flags are identical Initial Comment: From constants.h: /* access flags */ #define SVM_ACC_PUBLIC 0x0001 #define SVM_ACC_PRIVATE 0x0002 #define SVM_ACC_PROTECTED 0x0004 #define SVM_ACC_STATIC 0x0008 #define SVM_ACC_FINAL 0x0010 #define SVM_ACC_SUPER 0x0020 #define SVM_ACC_SYNCHRONIZED 0x0020 #define SVM_ACC_VOLATILE 0x0040 #define SVM_ACC_TRANSIENT 0x0080 #define SVM_ACC_NATIVE 0x0100 #define SVM_ACC_INTERFACE 0x0200 #define SVM_ACC_ABSTRACT 0x0400 #define SVM_ACC_STRICT 0x0800 #define SVM_ACC_INTERNAL 0x1000 ---------------------------------------------------------------------- >Comment By: Etienne M. Gagnon (egagnon) Date: 2003-03-16 11:09 Message: Logged In: YES user_id=15365 In the JVM specification [4.6 Methods] you can read: ACC_SYNCHRONIZED 0x0020 Declared synchronized; invocation is wrapped in a monitor lock. ---------------------------------------------------------------------- Comment By: Chris Pickett (ihatemcgill) Date: 2003-03-16 10:55 Message: Logged In: YES user_id=630752 /* access flags */ #define SVM_ACC_PUBLIC 0x0001 #define SVM_ACC_PRIVATE 0x0002 #define SVM_ACC_PROTECTED 0x0004 #define SVM_ACC_STATIC 0x0008 #define SVM_ACC_FINAL 0x0010 #define SVM_ACC_SUPER 0x0020 #define SVM_ACC_SYNCHRONIZED 0x0040 #define SVM_ACC_VOLATILE 0x0080 #define SVM_ACC_TRANSIENT 0x0100 #define SVM_ACC_NATIVE 0x0200 #define SVM_ACC_INTERFACE 0x0400 #define SVM_ACC_ABSTRACT 0x0800 #define SVM_ACC_STRICT 0x1000 #define SVM_ACC_INTERNAL 0x2000 is fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704531&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 15:42:40
|
Bugs item #704531, was opened at 2003-03-16 10:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704531&group_id=5523 Category: Other Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Chris Pickett (ihatemcgill) Assigned to: Nobody/Anonymous (nobody) Summary: super and synchronized access flags are identical Initial Comment: From constants.h: /* access flags */ #define SVM_ACC_PUBLIC 0x0001 #define SVM_ACC_PRIVATE 0x0002 #define SVM_ACC_PROTECTED 0x0004 #define SVM_ACC_STATIC 0x0008 #define SVM_ACC_FINAL 0x0010 #define SVM_ACC_SUPER 0x0020 #define SVM_ACC_SYNCHRONIZED 0x0020 #define SVM_ACC_VOLATILE 0x0040 #define SVM_ACC_TRANSIENT 0x0080 #define SVM_ACC_NATIVE 0x0100 #define SVM_ACC_INTERFACE 0x0200 #define SVM_ACC_ABSTRACT 0x0400 #define SVM_ACC_STRICT 0x0800 #define SVM_ACC_INTERNAL 0x1000 ---------------------------------------------------------------------- >Comment By: Chris Pickett (ihatemcgill) Date: 2003-03-16 10:55 Message: Logged In: YES user_id=630752 /* access flags */ #define SVM_ACC_PUBLIC 0x0001 #define SVM_ACC_PRIVATE 0x0002 #define SVM_ACC_PROTECTED 0x0004 #define SVM_ACC_STATIC 0x0008 #define SVM_ACC_FINAL 0x0010 #define SVM_ACC_SUPER 0x0020 #define SVM_ACC_SYNCHRONIZED 0x0040 #define SVM_ACC_VOLATILE 0x0080 #define SVM_ACC_TRANSIENT 0x0100 #define SVM_ACC_NATIVE 0x0200 #define SVM_ACC_INTERFACE 0x0400 #define SVM_ACC_ABSTRACT 0x0800 #define SVM_ACC_STRICT 0x1000 #define SVM_ACC_INTERNAL 0x2000 is fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704531&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 15:37:53
|
Bugs item #704533, was opened at 2003-03-16 10:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704533&group_id=5523 Category: Other Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Chris Pickett (ihatemcgill) Assigned to: Nobody/Anonymous (nobody) Summary: types should end in _t for better syntax highlighting Initial Comment: Change _svmt_* to _svmt_*_t for better syntax highlighting in all C files. It really is *much* more readable, even if there's an extra "_t". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704533&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 15:32:31
|
Bugs item #704531, was opened at 2003-03-16 10:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704531&group_id=5523 Category: Other Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Chris Pickett (ihatemcgill) Assigned to: Nobody/Anonymous (nobody) Summary: super and synchronized access flags are identical Initial Comment: From constants.h: /* access flags */ #define SVM_ACC_PUBLIC 0x0001 #define SVM_ACC_PRIVATE 0x0002 #define SVM_ACC_PROTECTED 0x0004 #define SVM_ACC_STATIC 0x0008 #define SVM_ACC_FINAL 0x0010 #define SVM_ACC_SUPER 0x0020 #define SVM_ACC_SYNCHRONIZED 0x0020 #define SVM_ACC_VOLATILE 0x0040 #define SVM_ACC_TRANSIENT 0x0080 #define SVM_ACC_NATIVE 0x0100 #define SVM_ACC_INTERFACE 0x0200 #define SVM_ACC_ABSTRACT 0x0400 #define SVM_ACC_STRICT 0x0800 #define SVM_ACC_INTERNAL 0x1000 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704531&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 15:17:00
|
Bugs item #704526, was opened at 2003-03-16 10:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704526&group_id=5523 Category: Other Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Pickett (ihatemcgill) Assigned to: Nobody/Anonymous (nobody) Summary: bytecode numbering Initial Comment: Hi, The instructions in constants.h correspond to the JVM spec bytecode numbering up until 201, after which point all instructions are SableVM-specific instructions. Is this ordering used to parse class files? If so, then the SableVM-specific instructions should start at 256. There are two reasons: 1) Sun may expand the bytecode set in the future, at which point it will be necessary to renumber things anyway. 2) I would like to use the "impdep1" and possibly "impdep2" opcodes, which have numbers 254 and 255. I want to transform a class file to have impdep1 / impdep2 opcodes using Soot, and so if this same ordering is really the ordering used to parse class files (I think it is), then I need those spots to be free. Currently, I am redefining PUTFIELD_INT and PUTFIELD_LONG from 254 and 255 to 333 and 334 respectively, but it is cleaner if everything is shifted down to start at 256. If this change is okay, I can make a patch with the renumbered instructions. Cheers, Chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704526&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 03:31:16
|
Bugs item #668111, was opened at 2003-01-14 15:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668111&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None >Priority: 3 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Etienne M. Gagnon (egagnon) Summary: Threads are leaked Initial Comment: When a thread exits, the memory associated with the thread is not freed. In addition, the thread is not put back on the free threads list associated with the VM. So the thread and its associated memory is leaked. In addition, the finalize() method is not overridden in java.lang.Thread. Guess that would be the logical place to free the memory and/or add the thread to the free list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=668111&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 03:30:41
|
Bugs item #704345, was opened at 2003-03-15 20:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704345&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None >Priority: 1 Submitted By: Chris Pickett (ihatemcgill) Assigned to: Nobody/Anonymous (nobody) Summary: optimization of method preparation Initial Comment: In Ch.2 of his thesis, Etienne explains the code preparation technique to replace slow instructions that must check for class initialization with faster ones (patching in code from the end of the code array at runtime). However, once a class is initialized, then for future preparation of methods that use this class, it is unnecessary to have either the slow version or the patch. The only cost of this optimization is an extra check at method preparation time for each instruction that requires class initialization, to see if the class has already been initialized. The savings are that 1) neither patching code nor slow initialization code needs to be prepared 2) there is no patching that ever takes place for that instruction and 3) (most importantly), we save at least one synchronization on the slow initialization instruction. This optimization is applicable to all three threading modes, but it will of course be most interesting to see if it improves inlined-threading. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704345&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 03:29:44
|
Bugs item #688936, was opened at 2003-02-18 14:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=688936&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Etienne M. Gagnon (egagnon) Assigned to: Etienne M. Gagnon (egagnon) Summary: Missing call to _svmf_set_current_env Initial Comment: While starting a new thread (in _svmf_thread_start), _svmf_set_current_env should be called to store the _svmt_JNIEnv pointer in the a thread-specific global variable. As it stands, now, when a signal handler is activated on any thread other than the main thread, SableVM aborts complaining about an unhandled signal in error.c line 170. ---------------------------------------------------------------------- Comment By: Chris Pickett (ihatemcgill) Date: 2003-02-25 00:14 Message: Logged In: YES user_id=630752 Suggested fix: change _svmf_thread_start in thread.c from containing: env->thread.pthread = pthread_self (); _svmm_invoke_static_virtualmachine_runthread (env); to env->thread.pthread = pthread_self (); + _svmf_set_current_env (env); _svmm_invoke_static_virtualmachine_runthread (env); This needs testing. The point is to fix multiprocessor support but I can't currently get SableVM working on a multiprocessor. P.S. My id / general online alias is just an old stand-by from when I was an undergraduate at McGill in biochemistry ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=688936&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 03:29:44
|
Bugs item #663270, was opened at 2003-01-06 14:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=663270&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Etienne M. Gagnon (egagnon) Summary: [jni: fatal error (Local reference capacity exceeded)] Initial Comment: I'm trying to run an application that uses Soot. If I try to process too many classfiles at once, I get this error plus a core dump: [jni: fatal error (Local reference capacity exceeded)] This makes SableVM suddenly look like a "toy" Java VM when we know it's really better than that :-) SableVM should handle this situation more gracefully, even if it means an 'escape' mechanism that's slower than normal or whatever. ---------------------------------------------------------------------- Comment By: Archie Cobbs (archiecobbs) Date: 2003-02-20 13:02 Message: Logged In: YES user_id=99943 Actually, a simpler way to fix this than using EnsureCapacity() is to use DeleteLocalRef() after assigning each parameter in the array. DeleteLocalRef() is already unimplemented. See attached patch. ---------------------------------------------------------------------- Comment By: Archie Cobbs (archiecobbs) Date: 2003-02-15 21:02 Message: Logged In: YES user_id=99943 I think the 'correct' way to fix this is: - Implement the JNI method EnsureCapacity() - In sablevm.c, call (*env)->EnsureCapacity() to guarantee there will be at least as many local native references available as there are parameters to main(). ---------------------------------------------------------------------- Comment By: Archie Cobbs (archiecobbs) Date: 2003-01-11 20:30 Message: Logged In: YES user_id=99943 Note: this happens if you give Sablevm more than 12 arguments on the command line. For example: $ sablevm 1 2 3 4 5 6 7 8 9 10 11 12 13 [jni: fatal error (Local reference capacity exceeded)] This seems like a real bug, rather than an JNI limitation or Classpath screwup.. (?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=663270&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 03:29:44
|
Bugs item #660598, was opened at 2002-12-31 22:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=660598&group_id=5523 Category: Execution Problem Group: SablePath >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Etienne M. Gagnon (egagnon) >Summary: String.getBytes(&quot;UTF8&quot;) is broken Initial Comment: There is a bug in the class gnu/java/io/encode/Encoder.java. If a String has a non-zero offset into its char[] array then things get screwey. The attached file UTF8.java demonstrates the bug. It generates this output: $ sablevm UTF8 bytes.length=20 bytes: 61 62 63 64 31 32 33 34 0 0 0 0 0 0 0 0 0 0 0 0 Other possibilities include the first byte being zero (!). ---------------------------------------------------------------------- Comment By: Archie Cobbs (archiecobbs) Date: 2003-01-01 21:03 Message: Logged In: YES user_id=99943 Previous patch is incomplete, new patch added. I've also submitted this bug to the classpath.org bug db. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=660598&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 03:29:44
|
Bugs item #653460, was opened at 2002-12-13 16:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=653460&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Etienne M. Gagnon (egagnon) >Summary: propery &quot;sablevm.stack.size.max&quot; ignored Initial Comment: There is no check for a thread's stack growing beyond the value set by the sablevm.stack.size.max property. See attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=653460&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 03:29:43
|
Bugs item #652416, was opened at 2002-12-11 20:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=652416&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Etienne M. Gagnon (egagnon) Summary: Minor optimization for new object alloc. Initial Comment: Why not this patch? memset() is often a lot faster than loops, as the compiler may know how to optimize specially for it... if so this patch should speed up every new object allocation. --- src/libsablevm/gc_copying.c.orig Tue Dec 10 11:51:13 2002 +++ src/libsablevm/gc_copying.c Tue Dec 10 11:51:34 2002 @@ -1054,14 +1054,7 @@ return JNI_ERR; } - { - size_t i; - - for (i = 0; i < instance_size; i++) - { - ((char *) result)[i] = 0; - } - } + memset(result, 0, instance_size); *pinstance = result; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=652416&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 03:29:43
|
Bugs item #651250, was opened at 2002-12-09 22:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=651250&group_id=5523 Category: Execution Problem Group: SablePath >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Etienne M. Gagnon (egagnon) Summary: Bug in LineNumberReader.java Initial Comment: I was trying to run an app and got an exception that looked like this: java.io.IOException: Pushback buffer is full at java.io.PushbackReader.unread(PushbackReader.java:319) at java.io.LineNumberReader.read(LineNumberReader.java:246) ... This appears to be a bug in LineNumberReader.java, which the patch below seems to fix. --- work/sablevm-class-library-1.0.5/src/java/io/LineNumberReader.java.orig Mon Dec 9 19:12:35 2002 +++ work/sablevm-class-library-1.0.5/src/java/io/LineNumberReader.java Mon Dec 9 19:12:02 2002 @@ -115,7 +115,7 @@ public LineNumberReader(Reader in, int size) { - super(new PushbackReader(in), size); + super(in, size); } /*************************************************************************/ @@ -243,7 +243,7 @@ int extra_char_read = super.read(); if ((extra_char_read != '\n') && (extra_char_read != -1)) - ((PushbackReader)in).unread(extra_char_read); + pos--; char_read = '\n'; ++line_number; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=651250&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 03:29:43
|
Bugs item #602543, was opened at 2002-08-30 13:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=602543&group_id=5523 Category: Compilation Problem Group: SablePath >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Archie Cobbs (archiecobbs) Assigned to: Etienne M. Gagnon (egagnon) >Summary: #include <malloc.h> is a Linux-ism Initial Comment: Please wrap instances of #include <malloc.h> within #ifdef HAVE_MALLOC_H . There are two instances in the sablevm-native-library tarball. <malloc.h> is a Linux-specific thing. All the world does not use Linux, sorry :-) ---------------------------------------------------------------------- Comment By: Etienne M. Gagnon (egagnon) Date: 2002-08-31 20:37 Message: Logged In: YES user_id=15365 This should be fixed in upstream GNU Classpath. I will do so. Etienne ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=602543&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 01:18:36
|
Bugs item #597356, was opened at 2002-08-19 16:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=597356&group_id=5523 Category: Execution Problem Group: SableVM >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Etienne M. Gagnon (egagnon) Summary: stack trace contains wrong line number Initial Comment: class LineNum { public static void main (String args[]) { try { // blank line // blank line // blank line ((Object)null).hashCode(); } catch (Exception c) { c.printStackTrace(); } } } This program prints: $ sablevm LineNum java.lang.NullPointerException at LineNum.main(LineNum.java:3) at java.lang.VirtualMachine.invokeMain(VirtualMachine.java) at java.lang.VirtualMachine.main(VirtualMachine.java:88) Notice the "LineNum.java:3" -- that should be "LineNum.java:7" instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=597356&group_id=5523 |
|
From: SourceForge.net <no...@so...> - 2003-03-16 01:18:20
|
Bugs item #704345, was opened at 2003-03-15 20:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704345&group_id=5523 Category: Execution Problem Group: SableVM Status: Open Resolution: None Priority: 5 Submitted By: Chris Pickett (ihatemcgill) Assigned to: Nobody/Anonymous (nobody) Summary: optimization of method preparation Initial Comment: In Ch.2 of his thesis, Etienne explains the code preparation technique to replace slow instructions that must check for class initialization with faster ones (patching in code from the end of the code array at runtime). However, once a class is initialized, then for future preparation of methods that use this class, it is unnecessary to have either the slow version or the patch. The only cost of this optimization is an extra check at method preparation time for each instruction that requires class initialization, to see if the class has already been initialized. The savings are that 1) neither patching code nor slow initialization code needs to be prepared 2) there is no patching that ever takes place for that instruction and 3) (most importantly), we save at least one synchronization on the slow initialization instruction. This optimization is applicable to all three threading modes, but it will of course be most interesting to see if it improves inlined-threading. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704345&group_id=5523 |
