search for: dellroad

Alkis Evlogimenos wrote: > On 4/25/06, Archie Cobbs <archie at dellroad.org> wrote: >> Motivation: Java's "first active use" requirement for class initialization. >> When invoking a static method, it's possible that a class may need to >> be initialized, However, when invoking an instance method, that's not >> possible....

On 4/25/06, Archie Cobbs <archie at dellroad.org> wrote: > Alkis Evlogimenos wrote: > > On 4/25/06, Archie Cobbs <archie at dellroad.org> wrote: > >> Motivation: Java's "first active use" requirement for class initialization. > >> When invoking a static method, it's possible that a class m...

On 4/25/06, Archie Cobbs <archie at dellroad.org> wrote: > Chris Lattner wrote: > > On Mon, 24 Apr 2006, Archie Cobbs wrote: > >> Related idea.. what if all instructions (not just "invoke") could be > >> allowed to have an optional "except label ..."? > > > > This is the direction...

>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: Archie> Perhaps it is. In which case, I guess we need something better or else Archie> we'll never be able to do certain optimizations. I'm curious to know which optimizations you have in mind. Tom

>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: Archie> In JCVM for example, there is a bit in type->flags that Archie> determines whether the class is initialized or not. This bit Archie> has to be checked before every static method invocation or Archie> static field access. You could reserve an entire byte inste...

Alkis Evlogimenos wrote: > On 4/25/06, Archie Cobbs <archie at dellroad.org> wrote: >> Alkis Evlogimenos wrote: >>> On 4/25/06, Archie Cobbs <archie at dellroad.org> wrote: >>>> Motivation: Java's "first active use" requirement for class initialization. >>>> When invoking a static method, it's possible t...

Tom Tromey wrote: >>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: > > Archie> In JCVM for example, there is a bit in type->flags that > Archie> determines whether the class is initialized or not. This bit > Archie> has to be checked before every static method invocation or > Archie> static field access. You could res...

>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: Are we bugging the LLVM folks with all this JVM talk? We could find (or make) another list to discuss this. Archie> E.g. devirtualization: this requires knowing the Java type Archie> (not LLVM type) of an object. But once you compile to LLVM, Archie> that information is...

>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: >> In the JIT, devirtualization looks doable, though somewhat fiddly. At >> least, that is true for straightforward things like calls to methods >> in final classes, or calls to methods on objects allocated with 'new' >> in the current function. (T...

Tom Tromey wrote: > Archie> Perhaps it is. In which case, I guess we need something better or else > Archie> we'll never be able to do certain optimizations. > > I'm curious to know which optimizations you have in mind. E.g. devirtualization: this requires knowing the Java type (not LLVM type) of an object. But once you compile to LLVM, that information is lost. If

Chris Lattner wrote: > On Wed, 26 Apr 2006, Archie Cobbs wrote: >>>> With no annotation support, it doesn't seem like you can. This is >>>> the problem. I'm not saying annotations are good, just that they >>>> represent one (sub-optimal) solution to the problem. Without them, >>>> we have zero solutions to the problem. >>>

On 29 Apr 2006 20:38:58 -0600, Tom Tromey <tromey at redhat.com> wrote: > >>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: > > >> In the JIT, devirtualization looks doable, though somewhat fiddly. At > >> least, that is true for straightforward things like calls to methods > >> in final classes, or calls to methods on objects allocated with 'new' > >> in t...

Tom Tromey wrote: > Are we bugging the LLVM folks with all this JVM talk? We could find > (or make) another list to discuss this. Probably :-) At least I think I understand things better now anyway and plan to pipe down a bit. > Archie> E.g. devirtualization: this requires knowing the Java type > Archie> (not LLVM type) of an object. But once you compile to LLVM, >

...ecessary Product: Portable OpenSSH Version: 4.6p1 Platform: All OS/Version: Linux Status: NEW Severity: enhancement Priority: P1 Component: ssh AssignedTo: bitbucket at mindrot.org ReportedBy: archie at dellroad.org Subject line says it all. The limit of 100 forwarded ports (e.g., using "-L" flag) is arbitrary and unnecessary. It is an example of what John Ousterhout would call a "voodoo constant", i.e., a value randomly chosen by a developer at some point in time without any basis i...

>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: Archie> Which bytecode will you recompile? In particular I'm thinking Archie> about active use checks: as you know the checks for class A have to Archie> be implemented in every other class B, C, D, ... that references a Archie> static field or method of A. Presumab...

On Wed, 26 Apr 2006, Archie Cobbs wrote: >>> With no annotation support, it doesn't seem like you can. This is >>> the problem. I'm not saying annotations are good, just that they >>> represent one (sub-optimal) solution to the problem. Without them, >>> we have zero solutions to the problem. >> >> Why do you believe this? > > Sorry,

Chris Lattner wrote: > On Mon, 24 Apr 2006, Archie Cobbs wrote: >> Related idea.. what if all instructions (not just "invoke") could be >> allowed to have an optional "except label ..."? > > This is the direction that we plan to go, when someone is interested > enough to implement it. There are some rough high-level notes about > this idea here:

On Mon, 24 Apr 2006, Archie Cobbs wrote: > Related idea.. what if all instructions (not just "invoke") could be > allowed to have an optional "except label ..."? This is the direction that we plan to go, when someone is interested enough to implement it. There are some rough high-level notes about this idea here:

Vikram Adve wrote: > If you're only interested in using LLVM for "cool things" (such as > optimization), you could use it directly on the C code you emit. Yes... though the translation to C loses some efficiency due to "impedance mismatch". More ideal would be to go from bytecode -> LLVM directly (I understand this part has already been done more or less). >

Chris Lattner wrote: > On Wed, 26 Apr 2006, Archie Cobbs wrote: >>> I haven't started this, so I have no idea how I would handle passing >>> the information back and forth. >> >> With no annotation support, it doesn't seem like you can. This is >> the problem. I'm not saying annotations are good, just that they >> represent one (sub-optimal)