harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: Architecture Questions - Moving to JreLite
Date Tue, 04 Mar 2008 13:50:21 GMT
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


Mime
View raw message