[EMAIL PROTECTED] wrote:
>
> > URL? Has this been factored into Hotspot? I don't think sacrificing OO
> > design is worth it for performance issues. It is like ECS, we have a
> > lot of object creation here but correct OO design wasn't sacrificed just
> > because you have a hot GC.
> >
> > --
> > Kevin A Burton ([EMAIL PROTECTED])
>
> I don't have a URL handy...I found out this information by attending a
> seminar put on at Sun by Sun that was about performance and JVM's. Doug
> Lea did a presentation about threading as well. It was quite good.
> Anyways, one of the main points that I took away from this is that stuff
> in try/catch blocks is not JIT optimized.
translation "our current VM doesn't do try/catch block JIT
optimization". This doesn't mean it is technically possible. A
hotspot VM should be able to handle this if a lot of exceptions are
thrown. If they are rarely thrown hotspot won't catch it but then again
if it is rarely thrown there is no need to optimize it :)
> The case with ECS has been solved through the use of better GC systems.
> Speed really isn't a concern there and on top of it, most of ECS can be
> JIT optimized. ;-)
Not all JITs. Some get hot here. The volano benchmarks have this.
They have some code that is highly object intensive and they throw them
to different VMs and some choak.
> As for the statement about OO or not OO. I really don't think that it
> makes Turbine not OO to not be throwing a TurbineException. I think that
> your complaint here is fairly moot because if something throws an SQL
> Exception and you actually care that it is an SQLException, then you
> should be catching that yourself already (that is regarding your code
> example of having both Turbine code and SQL code in the same try/catch
> block).
>
> public void fooBar()
> throws Exception
> {
> try
> {
> // Turbine code
> // JDBC code
> }
> catch (SQLException e)
> {}
> }
>
> In your example, you are presuming that you care about SQLExceptions. In
> the above example, you will catch them and be able to deal with them.
> Turbine code will get passed back up the chain to be caught later. Of
> course the above example will prevent that code from being JIT optimized
> as well which is a bad thing again...
It isn't something that is worth arguing over. If you are right then
nothing happens. If I am write then we have a bad architecture and
throwing TurbineException is good. As long as there are no drawbacks to
doing this we should go with it. It isn't the best everywhere but if we
have to "new Exception()" something then that should totally be a "new
TurbineException()". Other situations where the code can't be JITed
might be bad. But then again we don't want our code to throw exceptions
all the time.
Kevin
--
Kevin A Burton ([EMAIL PROTECTED])
http://relativity.yi.org
Message to SUN: "Open Source Java!"
"For evil to win is for good men to do nothing."
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
