classpath-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cp-patches] [RFC/JDWP] ID management


From: Keith Seitz
Subject: Re: [cp-patches] [RFC/JDWP] ID management
Date: Tue, 09 Aug 2005 13:23:34 -0700

On Tue, 2005-08-09 at 16:12 -0400, Bryce McKinlay wrote:

> Right. These "special" classes are all clearly identified by having VM 
> prefixed to their name. They're also found in a separate location in the 
> classpath build tree (vm/reference). It's done this way mostly for 
> efficiency - using an service-provider approach would force everything 
> to aquire the implementation object and make a virtual call, which is 
> clearly much too heavy in some cases.

Ah -- I keep forgetting about the run-time overhead of these different
approaches! Shame on me!

> For JDWP, you don't have to use this model, of course. If you think it 
> makes development/maintainance easier then you could use an SPI. For one 
> thing, you'd be able to build both, say, the reference and gcj-specific 
> implementations at the same time. I just wanted to make sure you were 
> aware of the alternative :)

No, I think that you are correct to make me aware of this: it _does_
make a difference, and quite frankly, it should simply a few things,
too, I think!

I am refactoring my code now and I will post a follow-up shortly.

> >My only hesitation with moving it out of IdManager is that IdManager is
> >the one place where sizes for IDs are (or at least should/could be)
> >known. The rest of the code (IDSizes excepted right now) knows nothing
> >about this.

> Ah, yes. And the sizes are VM-specific. Good point!

Yeah, they are, but right now, we assume everything is eight bytes --
largely because I don't want to have to deal with opaque types for 2-
byte, 4-byte, and 8-byte ID lengths. IMO, it's just another complication
that I don't need to deal with at the moment. By minimizing any of these
assumptions into the code, we should be able to minimize the pain of
"upgrading". Of course, now that I think about it, with the non-SPI way
of doing things, this all becomes much more trivial to implement
generically! Bonus awarded! :-)

Keith





reply via email to

[Prev in Thread] Current Thread [Next in Thread]