[Top][All Lists]
[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