You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Johnny Kewl <jo...@kewlstuff.co.za> on 2008/03/04 10:56:30 UTC
Architecture Questions - Moving to JreLite
Newbie... please be gentle ;)
In relation to the *VM* how are these used and are they used at all, if so
why.
BCEL?
(Probably introspection)
ICU?
(Unicode... its too big to be good)
XALAN
(please no)
XERCES
(please no)
Yoko
(Corba... I hope not)
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
Two JIT compilers ... beautiful, the OPT compiler must be optional or late
loading, its perfect, if they can be separated?
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?
Thanks... Harmony is great...
Re: Architecture Questions - Moving to JreLite
Posted by Pavel Pervov <pm...@gmail.com>.
Mark,
I've mistaken, DRLVM uses ICU4C, not ICU4JNI.
Re iswalpha and iswalnum - they are available both on Windows and
Linux - but are not identical to ICU4C functions.
Pavel.
On 3/6/08, Mark Hindess <ma...@googlemail.com> wrote:
>
> On 4 March 2008 at 13:49, "Pavel Pervov" <pm...@gmail.com> wrote:
> > Johnny,
> >
> > see inline.
> >
> > On 3/4/08, Johnny Kewl <jo...@kewlstuff.co.za> 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.
>
> Pavel,
>
> Is that right? I thought DRLVM only used ICU4C and that now that
> classlib only uses ICU4J that nothing needed ICU4JNI[0].
>
> I thought that DRLVM only used the u_isalpha and u_isalnum functions
> from ICU4C. I assume it isn't possible to use the "standard" iswalpha
> and iswalnum instead?
>
> -Mark.
>
> [0] I notice that we still included the real version of the ICUInterface
> dll in the M5 binaries but I'm pretty sure nothing should need it.
> Even the empty stub dll (in classlib) is only needed to keep the IBM
> VME happy.
>
> > > 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.
> >
> > > Where are fonts actually used, not directly in the VM I hope, ie its AWT an
> > d
> > > 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.
> >
>
>
>
>
>
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
Re: Architecture Questions - Moving to JreLite
Posted by Alexey Varlamov <al...@gmail.com>.
2008/3/6, Mark Hindess <ma...@googlemail.com>:
>
> > Which ICU? ICU4J is class library implementation of locales. ICU4JNI
> > is used by DRLVM for verifying java identifiers.
>
> Pavel,
>
> Is that right? I thought DRLVM only used ICU4C and that now that
> classlib only uses ICU4J that nothing needed ICU4JNI[0].
>
> I thought that DRLVM only used the u_isalpha and u_isalnum functions
> from ICU4C. I assume it isn't possible to use the "standard" iswalpha
> and iswalnum instead?
Mark,
I believe you are right. FYI, I filed related HARMONY-5556 which
should be easy to fix with iswalpha/iswalnum.
--
Alexey
>
> -Mark.
>
> [0] I notice that we still included the real version of the ICUInterface
> dll in the M5 binaries but I'm pretty sure nothing should need it.
> Even the empty stub dll (in classlib) is only needed to keep the IBM
> VME happy.
Re: Architecture Questions - Moving to JreLite
Posted by Mark Hindess <ma...@googlemail.com>.
On 4 March 2008 at 13:49, "Pavel Pervov" <pm...@gmail.com> wrote:
> Johnny,
>
> see inline.
>
> On 3/4/08, Johnny Kewl <jo...@kewlstuff.co.za> 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.
Pavel,
Is that right? I thought DRLVM only used ICU4C and that now that
classlib only uses ICU4J that nothing needed ICU4JNI[0].
I thought that DRLVM only used the u_isalpha and u_isalnum functions
from ICU4C. I assume it isn't possible to use the "standard" iswalpha
and iswalnum instead?
-Mark.
[0] I notice that we still included the real version of the ICUInterface
dll in the M5 binaries but I'm pretty sure nothing should need it.
Even the empty stub dll (in classlib) is only needed to keep the IBM
VME happy.
> > 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.
>
> > Where are fonts actually used, not directly in the VM I hope, ie its AWT an
> d
> > 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.
>
Re: Architecture Questions - Moving to JreLite
Posted by Johnny Kewl <jo...@kewlstuff.co.za>.
----- Original Message -----
From: "Pavel Pervov" <pm...@gmail.com>
To: <de...@harmony.apache.org>
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 <eg...@gmail.com> wrote:
>> On the 0x3FD day of Apache Harmony Pavel Pervov wrote:
>> > Johnny,
>> >
>> > see inline.
>> >
>> > On 3/4/08, Johnny Kewl <jo...@kewlstuff.co.za> 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
>
Re: Architecture Questions - Moving to JreLite
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x3FD day of Apache Harmony Mikhail Fursov wrote:
> Neither OPT or JET depends on each other.
>
> They both do depends on 1) PMF 2) Logging 3) JITInstanceContext and
> EMInterface wrapper 4) mkernel utils.
> All these common files are located in OPT folders.
>
> IMO we can separate OPT from JET and get as a result 70-80% size reduction
> for jitrino.dll with JET only compiler.
>
> The separation of sources doesn't look practical.
+1
> At least, it requires to design fine-grain interfaces for all the
> shared components listed above. The compile-time switch to build
> jitrino.dll with the only one compiler included looks reasonable to
> me.
hm, and another dll/so for OPT to use the light lib :)
> On 04 Mar 2008 16:50:21 +0300, Egor Pasko <eg...@gmail.com> wrote:
>
> > On the 0x3FD day of Apache Harmony Pavel Pervov wrote:
> > > 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.
> >
> > JET does not use collections, shared stuff is:
> >
> > PMF, Logging, MemoryManager, microkernel, IEEE754_fmod_double, tiny
> > platform-dependant stuff
> >
> > I believe it fits into 500K or maybe 200K :)
> >
> > > Completing your idea we can move shared code into dynamic lib and use
> > > it dynamically from both JITs.
> > >
> > > Pavel.
> > >
> > > On 04 Mar 2008 16:08:32 +0300, Egor Pasko <eg...@gmail.com> wrote:
> > > > On the 0x3FD day of Apache Harmony Pavel Pervov wrote:
> > > > > Johnny,
> > > > >
> > > > > see inline.
> > > > >
> > > > > On 3/4/08, Johnny Kewl <jo...@kewlstuff.co.za> 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
> > >
> >
> > --
> > Egor Pasko
> >
> >
>
>
> --
> Mikhail Fursov
--
Egor Pasko
Re: Architecture Questions - Moving to JreLite
Posted by Mikhail Fursov <mi...@gmail.com>.
Neither OPT or JET depends on each other.
They both do depends on 1) PMF 2) Logging 3) JITInstanceContext and
EMInterface wrapper 4) mkernel utils.
All these common files are located in OPT folders.
IMO we can separate OPT from JET and get as a result 70-80% size reduction
for jitrino.dll with JET only compiler.
The separation of sources doesn't look practical. At least, it requires to
design fine-grain interfaces for all the shared components listed above.
The compile-time switch to build jitrino.dll with the only one compiler
included looks reasonable to me.
On 04 Mar 2008 16:50:21 +0300, Egor Pasko <eg...@gmail.com> wrote:
> On the 0x3FD day of Apache Harmony Pavel Pervov wrote:
> > 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.
>
> JET does not use collections, shared stuff is:
>
> PMF, Logging, MemoryManager, microkernel, IEEE754_fmod_double, tiny
> platform-dependant stuff
>
> I believe it fits into 500K or maybe 200K :)
>
> > Completing your idea we can move shared code into dynamic lib and use
> > it dynamically from both JITs.
> >
> > Pavel.
> >
> > On 04 Mar 2008 16:08:32 +0300, Egor Pasko <eg...@gmail.com> wrote:
> > > On the 0x3FD day of Apache Harmony Pavel Pervov wrote:
> > > > Johnny,
> > > >
> > > > see inline.
> > > >
> > > > On 3/4/08, Johnny Kewl <jo...@kewlstuff.co.za> 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
> >
>
> --
> Egor Pasko
>
>
--
Mikhail Fursov
Re: Architecture Questions - Moving to JreLite
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x3FD day of Apache Harmony Pavel Pervov wrote:
> 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.
JET does not use collections, shared stuff is:
PMF, Logging, MemoryManager, microkernel, IEEE754_fmod_double, tiny
platform-dependant stuff
I believe it fits into 500K or maybe 200K :)
> Completing your idea we can move shared code into dynamic lib and use
> it dynamically from both JITs.
>
> Pavel.
>
> On 04 Mar 2008 16:08:32 +0300, Egor Pasko <eg...@gmail.com> wrote:
> > On the 0x3FD day of Apache Harmony Pavel Pervov wrote:
> > > Johnny,
> > >
> > > see inline.
> > >
> > > On 3/4/08, Johnny Kewl <jo...@kewlstuff.co.za> 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
>
--
Egor Pasko
Re: Architecture Questions - Moving to JreLite
Posted by Pavel Pervov <pm...@gmail.com>.
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.
On 04 Mar 2008 16:08:32 +0300, Egor Pasko <eg...@gmail.com> wrote:
> On the 0x3FD day of Apache Harmony Pavel Pervov wrote:
> > Johnny,
> >
> > see inline.
> >
> > On 3/4/08, Johnny Kewl <jo...@kewlstuff.co.za> 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
Re: Architecture Questions - Moving to JreLite
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x3FD day of Apache Harmony Pavel Pervov wrote:
> Johnny,
>
> see inline.
>
> On 3/4/08, Johnny Kewl <jo...@kewlstuff.co.za> 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
Re: Architecture Questions - Moving to JreLite
Posted by Pavel Pervov <pm...@gmail.com>.
Johnny,
see inline.
On 3/4/08, Johnny Kewl <jo...@kewlstuff.co.za> 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.
> 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.
Re: Architecture Questions - Moving to JreLite
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x3FE day of Apache Harmony Xiao-Feng Li wrote:
> On Wed, Mar 5, 2008 at 9:50 AM, Johnny Kewl <jo...@kewlstuff.co.za> wrote:
> >
> >
> > ----- Original Message -----
> > From: "Xiao-Feng Li" <xi...@gmail.com>
> > To: <de...@harmony.apache.org>
> > Sent: Tuesday, March 04, 2008 3:36 PM
> > Subject: Re: Architecture Questions - Moving to JreLite
> >
> >
> > > On Tue, Mar 4, 2008 at 5:56 PM, Johnny Kewl <jo...@kewlstuff.co.za> wrote:
> > >> Newbie... please be gentle ;)
> > >>
> > >> In relation to the *VM* how are these used and are they used at all, if
> > >> so
> > >> why.
> > >>
> > >> BCEL?
> > >> (Probably introspection)
> > >>
> > >> ICU?
> > >> (Unicode... its too big to be good)
> > >>
> > >> XALAN
> > >> (please no)
> > >>
> > >> XERCES
> > >> (please no)
> > >>
> > >> Yoko
> > >> (Corba... I hope not)
> > >>
> > >>
> > >> 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
> > >>
> > >> Two JIT compilers ... beautiful, the OPT compiler must be optional or
> > >> late
> > >> loading, its perfect, if they can be separated?
> > >
> > > Well, I would suggest to approach the interesting JreLite project in
> > > two almost independent phases. One is to deal with the non-VM stuff,
> > > the other is to deal with the VM itself. The second phase might be
> > > more challenging, but not really urgent, in my opinion.
> > >
> > > Btw, Johnny, have you any expectation on the size of JreLite? 10MB? 1MB?
> >
> > Yes this is the million dollar question....
> > I think an initial HIT of 3 megs is MAX... thats what I want to try get it
> > to...
> > That must be possible, because as I see the technology, it will be more
> > efficient than Java Embedded, and that comes in at 5meg..
> > I think even smaller is possible, but if JavaLite only makes an initial HIT
> > of 3 megs.... Java is as free as a bird.
> > Applications will be starting from email and the browser...
> > Remember that the user does not install JreLite... they install a 80k boot
> > strap program called JRELite... so no pain.
> > The bootstrap JRELite is the initial loaded and platform detector... so what
> > it feels like to the user, is that the "first" app they run
> > is configuring the system.... the typical "Microsfot is now configuring your
> > system" message... then the app starts, its not finished downloading
> > but its running.... my guess, first time run on ADSL... 15 seconds before
> > the user see's it start....
> >
> > A 3 meg hit I think is a worst case... but even at that.... java has jumped
> > out of it cage ;)
> >
> >
>
> Ok, 3MB is quite ambitious. ;) I think it's possible. But the problem
> to attack then changes: in my previous email, I said the project
> should probably start from the non-VM stuff, i.e., classlib packages;
> for 3MB JRE, now I would suggest to start from the direct VM part. You
> see the JIT already takes more than 3MB, and the VMcore as well. And
> once this is achieved, the non-VM part could be easier.
I support the idea of starting from non-VM part in this project.
> It's an install(.exe) application that is small and, as you said, can
> detect the platform and download necessary components. This installer
> is associated (or built-in) with the distributable Java applications.
> The user can simply launch (say, double click) the Java application
> without knowing about the JRE stuff. The installer will do three
> things:
> 1. start the app (primitively);
> 2. check if any components are missing or desirable;
> 3. check the platform if the missing components are installed already;
> 4. download the missing parts.
>
> Thanks,
> xiaofeng
>
> > >
> > > Thanks,
> > > xiaofeng
> > >
> > >> 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?
> > >>
> > >> Thanks... Harmony is great...
> > >>
> > >>
> > >
> > >
> > >
> > > --
> > > http://xiao-feng.blogspot.com
> > >
> >
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>
--
Egor Pasko
Re: Architecture Questions - Moving to JreLite
Posted by Xiao-Feng Li <xi...@gmail.com>.
On Wed, Mar 5, 2008 at 9:50 AM, Johnny Kewl <jo...@kewlstuff.co.za> wrote:
>
>
> ----- Original Message -----
> From: "Xiao-Feng Li" <xi...@gmail.com>
> To: <de...@harmony.apache.org>
> Sent: Tuesday, March 04, 2008 3:36 PM
> Subject: Re: Architecture Questions - Moving to JreLite
>
>
> > On Tue, Mar 4, 2008 at 5:56 PM, Johnny Kewl <jo...@kewlstuff.co.za> wrote:
> >> Newbie... please be gentle ;)
> >>
> >> In relation to the *VM* how are these used and are they used at all, if
> >> so
> >> why.
> >>
> >> BCEL?
> >> (Probably introspection)
> >>
> >> ICU?
> >> (Unicode... its too big to be good)
> >>
> >> XALAN
> >> (please no)
> >>
> >> XERCES
> >> (please no)
> >>
> >> Yoko
> >> (Corba... I hope not)
> >>
> >>
> >> 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
> >>
> >> Two JIT compilers ... beautiful, the OPT compiler must be optional or
> >> late
> >> loading, its perfect, if they can be separated?
> >
> > Well, I would suggest to approach the interesting JreLite project in
> > two almost independent phases. One is to deal with the non-VM stuff,
> > the other is to deal with the VM itself. The second phase might be
> > more challenging, but not really urgent, in my opinion.
> >
> > Btw, Johnny, have you any expectation on the size of JreLite? 10MB? 1MB?
>
> Yes this is the million dollar question....
> I think an initial HIT of 3 megs is MAX... thats what I want to try get it
> to...
> That must be possible, because as I see the technology, it will be more
> efficient than Java Embedded, and that comes in at 5meg..
> I think even smaller is possible, but if JavaLite only makes an initial HIT
> of 3 megs.... Java is as free as a bird.
> Applications will be starting from email and the browser...
> Remember that the user does not install JreLite... they install a 80k boot
> strap program called JRELite... so no pain.
> The bootstrap JRELite is the initial loaded and platform detector... so what
> it feels like to the user, is that the "first" app they run
> is configuring the system.... the typical "Microsfot is now configuring your
> system" message... then the app starts, its not finished downloading
> but its running.... my guess, first time run on ADSL... 15 seconds before
> the user see's it start....
>
> A 3 meg hit I think is a worst case... but even at that.... java has jumped
> out of it cage ;)
>
>
Ok, 3MB is quite ambitious. ;) I think it's possible. But the problem
to attack then changes: in my previous email, I said the project
should probably start from the non-VM stuff, i.e., classlib packages;
for 3MB JRE, now I would suggest to start from the direct VM part. You
see the JIT already takes more than 3MB, and the VMcore as well. And
once this is achieved, the non-VM part could be easier.
It's an install(.exe) application that is small and, as you said, can
detect the platform and download necessary components. This installer
is associated (or built-in) with the distributable Java applications.
The user can simply launch (say, double click) the Java application
without knowing about the JRE stuff. The installer will do three
things:
1. start the app (primitively);
2. check if any components are missing or desirable;
3. check the platform if the missing components are installed already;
4. download the missing parts.
Thanks,
xiaofeng
> >
> > Thanks,
> > xiaofeng
> >
> >> 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?
> >>
> >> Thanks... Harmony is great...
> >>
> >>
> >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
>
--
http://xiao-feng.blogspot.com
Re: Architecture Questions - Moving to JreLite
Posted by Johnny Kewl <jo...@kewlstuff.co.za>.
----- Original Message -----
From: "Xiao-Feng Li" <xi...@gmail.com>
To: <de...@harmony.apache.org>
Sent: Tuesday, March 04, 2008 3:36 PM
Subject: Re: Architecture Questions - Moving to JreLite
> On Tue, Mar 4, 2008 at 5:56 PM, Johnny Kewl <jo...@kewlstuff.co.za> wrote:
>> Newbie... please be gentle ;)
>>
>> In relation to the *VM* how are these used and are they used at all, if
>> so
>> why.
>>
>> BCEL?
>> (Probably introspection)
>>
>> ICU?
>> (Unicode... its too big to be good)
>>
>> XALAN
>> (please no)
>>
>> XERCES
>> (please no)
>>
>> Yoko
>> (Corba... I hope not)
>>
>>
>> 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
>>
>> Two JIT compilers ... beautiful, the OPT compiler must be optional or
>> late
>> loading, its perfect, if they can be separated?
>
> Well, I would suggest to approach the interesting JreLite project in
> two almost independent phases. One is to deal with the non-VM stuff,
> the other is to deal with the VM itself. The second phase might be
> more challenging, but not really urgent, in my opinion.
>
> Btw, Johnny, have you any expectation on the size of JreLite? 10MB? 1MB?
Yes this is the million dollar question....
I think an initial HIT of 3 megs is MAX... thats what I want to try get it
to...
That must be possible, because as I see the technology, it will be more
efficient than Java Embedded, and that comes in at 5meg..
I think even smaller is possible, but if JavaLite only makes an initial HIT
of 3 megs.... Java is as free as a bird.
Applications will be starting from email and the browser...
Remember that the user does not install JreLite... they install a 80k boot
strap program called JRELite... so no pain.
The bootstrap JRELite is the initial loaded and platform detector... so what
it feels like to the user, is that the "first" app they run
is configuring the system.... the typical "Microsfot is now configuring your
system" message... then the app starts, its not finished downloading
but its running.... my guess, first time run on ADSL... 15 seconds before
the user see's it start....
A 3 meg hit I think is a worst case... but even at that.... java has jumped
out of it cage ;)
>
> Thanks,
> xiaofeng
>
>> 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?
>>
>> Thanks... Harmony is great...
>>
>>
>
>
>
> --
> http://xiao-feng.blogspot.com
>
Re: Architecture Questions - Moving to JreLite
Posted by Xiao-Feng Li <xi...@gmail.com>.
On Tue, Mar 4, 2008 at 5:56 PM, Johnny Kewl <jo...@kewlstuff.co.za> wrote:
> Newbie... please be gentle ;)
>
> In relation to the *VM* how are these used and are they used at all, if so
> why.
>
> BCEL?
> (Probably introspection)
>
> ICU?
> (Unicode... its too big to be good)
>
> XALAN
> (please no)
>
> XERCES
> (please no)
>
> Yoko
> (Corba... I hope not)
>
>
> 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
>
> Two JIT compilers ... beautiful, the OPT compiler must be optional or late
> loading, its perfect, if they can be separated?
Well, I would suggest to approach the interesting JreLite project in
two almost independent phases. One is to deal with the non-VM stuff,
the other is to deal with the VM itself. The second phase might be
more challenging, but not really urgent, in my opinion.
Btw, Johnny, have you any expectation on the size of JreLite? 10MB? 1MB?
Thanks,
xiaofeng
> 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?
>
> Thanks... Harmony is great...
>
>
--
http://xiao-feng.blogspot.com
Re: Architecture Questions - Moving to JreLite
Posted by Nathan Beyer <nb...@gmail.com>.
On Tue, Mar 4, 2008 at 3:56 AM, Johnny Kewl <jo...@kewlstuff.co.za> wrote:
> Newbie... please be gentle ;)
>
> In relation to the *VM* how are these used and are they used at all, if so
> why.
>
> BCEL?
> (Probably introspection)
>
> ICU?
> (Unicode... its too big to be good)
Unicode is too big or ICU is too big? You do realize that Unicode
support is required by the Java language specification, amongst other
specifications.
>
> XALAN
> (please no)
>
> XERCES
> (please no)
>
> Yoko
> (Corba... I hope not)
>
>
> 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
>
> Two JIT compilers ... beautiful, the OPT compiler must be optional or late
> loading, its perfect, if they can be separated?
>
> 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?
>
> Thanks... Harmony is great...
>
>
Re: Architecture Questions - Moving to JreLite
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x3FD day of Apache Harmony Johnny Kewl wrote:
> Newbie... please be gentle ;)
>
> In relation to the *VM* how are these used and are they used at all,
> if so why.
>
> BCEL?
> (Probably introspection)
>
> ICU?
> (Unicode... its too big to be good)
>
> XALAN
> (please no)
>
> XERCES
> (please no)
>
> Yoko
> (Corba... I hope not)
>
>
> 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
>
> Two JIT compilers ... beautiful, the OPT compiler must be optional or
> late loading, its perfect, if they can be separated?
BTW, OPT is reasonable when a single loop in your program appears. So,
basically, one would want to download OPT right on the first
invocation.
currently both compilers take 2 MB in a stripped library, this is
mainly OPT.
For a mouse-oriented user there is a big question, when s/he wants
OPT, but for apt-like pachage management this question is simple and
does not require a major VM redesign.
> 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?
>
> Thanks... Harmony is great...
--
Egor Pasko