----- Original Message -----
From: "Pavel Pervov" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, March 04, 2008 3:36 PM
Subject: Re: Architecture Questions - Moving to JreLite
Egor,
I had an argument with JIT guys some time earlier about splitting JET
and OPT into separate libraries. Their main argument was "shared
code". AFAIR it was memory management, collections, and logging.
Completing your idea we can move shared code into dynamic lib and use
it dynamically from both JITs.
Pavel.
Pavel dont worry too much about the core JVM.... JIT etc... that could come
later.
When people see JRELite working I think it will create a whole new creative
angle.
But... non running developer tools, fonts and core classes... have to be
made "late loading".
Also if someone is even thinking of making the JRE dependent on packages
like XALAN or Xerces
we will have to kill you ;) ... it will absolutely destroy JreLite...
..... you see I think we talking a 3 meg hit... maybe 4 meg...
Engines optimizations like a late binding JIT, may save 1 meg... or may save
a meg initially and
put back 1.5 megs... and what we talking about is the time do download 1
meg... nice
opts but maybe not worth months of design to just see how JreLite works...
it can come later
2-3-4 megs ok.... 10 megs up an its dead... so as long as it comes in at
around 3 megs initial hit...
.... I think its working ;)
I think its sensible to target it at ADSL type speeds... if its a nice 20
second experience there... it works.
On 04 Mar 2008 16:08:32 +0300, Egor Pasko <[EMAIL PROTECTED]> wrote:
On the 0x3FD day of Apache Harmony Pavel Pervov wrote:
> Johnny,
>
> see inline.
>
> On 3/4/08, Johnny Kewl <[EMAIL PROTECTED]> wrote:
>
> > ICU?
> > (Unicode... its too big to be good)
> Which ICU? ICU4J is class library implementation of locales. ICU4JNI
> is used by DRLVM for verifying java identifiers.
>
> > Its almost perfect, the only area that naturally needs work is that
> > the VM
> > does not distinguish between a user using the program and a
> > programmer
> > that wants extra functionality... So Debuggers profiling tooling has
> > to be
> > made all optional and dynamic links
> Its possible, but VM has lots of hooks inside of it related to JVMTI,
> and JVMTI itself is not blazingly fast. Separating into dynamic
> linkage won't make things faster.
>
> > Two JIT compilers ... beautiful, the OPT compiler must be optional or
> > late
> > loading, its perfect, if they can be separated?
> In short - no. In more details, JET and OPT has lots of common
> functionality and separating them whould mean bigger code size.
by lots you mean not very lots, right? :)
the simple (and possibly incorect) solution might be to package two
libraries based on jitrino/src subdirectories:
1. jet+shared+main (jet.{so,dll})
2. the rest (opt.{so,dll})
now opt depends on jet, yey (not ery good for systems, where we do not
support jet, but those systems are packaged differently anyway)
looks like rather easy and with no big increase in code size..
> > Where are fonts actually used, not directly in the VM I hope, ie its
> > AWT and
> > Swing classes, that *once loaded use them*, is that right?
> > Something like classloader loads up a Swing class, it draws, this is
> > a
> > method call outside VM logic and links straight out to a system dll?
> > Where is the native side of AWT and SWING living... in harmonyvm.dll?
> harmonyvm.dll is the virtual machine itself. Harmony is pretty modular
> and does not mix dependencies (well, does not mix lots of dependencies
> ;)).
>
> > Thanks... Harmony is great...
> This is unquestionable. ;)
>
> Pavel.
>
--
Egor Pasko
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
