harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fedotov, Alexei A" <alexei.a.fedo...@intel.com>
Subject RE: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)
Date Mon, 30 Oct 2006 21:07:09 GMT
Geir wrote,
>Not only that, we create a class library that places **weird**
requirements
>on any VM that wants to use it.

Ok, I believe this was honest. :-) As far as I know the optimization
Mikhail is talking about is nearly standard for any optimizing JIT. 

Isn't it just a simple inlining? I accept that inlining in Java is a bit
more complex, than in C, since you can load classes and redefine methods
on fly. Anyway optimizing JIT recompiles the whole thing when such event
happens and an appropriate callback is called.

With best regards,
Alexei Fedotov,
Intel Java & XML Engineering

>-----Original Message-----
>From: Geir Magnusson Jr. [mailto:geir@pobox.com]
>Sent: Monday, October 30, 2006 9:29 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code
smell -
>Thread.sleep() in ActivationGroup method)
>
>
>
>Alexei Zakharov wrote:
>> Hi all,
>>
>> Well, as an individual who has the tendency to pure Java programming
I
>> will be happier if I can control things on the source-code level. I
>> can't say I don't like the idea about sophisticated JIT with the
>> powerful AI inside, but if we are talking about logging then IMHO a
>> good preprocessor is the thing that we need (but we may also continue
>> to JIT away stuff if we like).
>
>Not only that, we create a class library that places weird requirements
>on any VM that wants to use it.  No thanks.
>
> > At the same time I don't feel
>> completely comfortable with the idea of using preprocessor to
separate
>> J2SE sources from J2ME.
>
>I'm not overjoyed either, but I can't think of many ways that allow
>fairly clear readability without don't require tons of IDE-specific
>tooling.  This is what bothers me about aspects - can you get a real
>clue what's going to happen looking at the source code?
>
>geir
>
>>
>> No clue about particular technology. It can be SableCC, something
>> custom-made, velocity or whatever.
>>
>> Thanks,
>>
>> 2006/10/30, Fedotov, Alexei A <alexei.a.fedotov@intel.com>:
>>>                        Premature optimization is the root of all
evil
>>>                                Donald Knuth
>>>
>>>
>>> >Just a small idea: Let teach JIT to purge this code unless special
>>> option
>>> >is ON
>>>
>>> +1
>>>
>>> I believe a computer should adapt to my way of thinking. I prefer a
>>> simple and readable code to an efficient one since the former one
saves
>>> the time of my life, why the latter one saves some electricity.
>>>
>>> With best regards,
>>> Alexei Fedotov,
>>> Intel Java & XML Engineering
>>>
>>> >-----Original Message-----
>>> >From: Mikhail Fursov [mailto:mike.fursov@gmail.com]
>>> >Sent: Sunday, October 29, 2006 8:56 PM
>>> >To: harmony-dev@incubator.apache.org; geir@pobox.com
>>> >Subject: Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code
>>> smell -
>>> >Thread.sleep() in ActivationGroup method)
>>> >
>>> >On 10/29/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>>> >>
>>> >>
>>> >> 1) The Logging Debate That Won't Die - we don't want to encumber
our
>>> >> "production" code with logging or even with runtime enablement
checks
>>> >> for logging i.e.
>>> >>
>>> >>       if (logging.isDebugEnabled())
>>> >>
>>> >> but it's clear that some people still want to use it for
debugging.
>>> >
>>> >
>>> >Just a small idea: Let teach JIT to purge this code unless special
>>> option
>>> >is ON
>>> >? Doing this we solve performance issue at least .
>>> >
>>> >If we did this, I assume that our build becomes a two step process,
>>> >> first pre-process the code to create  separate "buildable
source",
>>> which
>>> >> would go into source jars and such for debugging purposes.  Then
our
>>> >> current javac/jar process.
>>> >>
>>> >> I'd also like to be able to work in an IDE with the pre-proc
stuff
>>> >> invisible if possible...
>>> >
>>> >
>>> >This is the main problem. Backporting of your changes from the
>>> "buildable
>>> >source" to the "source with preprocessor" could have more overhead
then
>>> >support of a separate branch for different Java version.
>>
>>

Mime
View raw message