harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: Architecture Questions - Moving to JreLite
Date Tue, 04 Mar 2008 14:10:30 GMT
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 <egor.pasko@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 <egor.pasko@gmail.com> wrote:
> > > On the 0x3FD day of Apache Harmony Pavel Pervov wrote:
> > > > Johnny,
> > > >
> > > > see inline.
> > > >
> > > > On 3/4/08, Johnny Kewl <john@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message