Re: This week on harmony-dev (Aug. 28 - Sept. 03 2005)
On Mon, 2005-09-05 at 16:54 +0100, Tim Ellison wrote:
> I think these summaries are great David, keep it up!
Thank you, it's good to hear that. I really appreciate any feedback,
so if some of you might have any suggestions what I could change
(go more/less into detail, or whatever) please tell me.
> [ ...though it does make the little devil inside me want to start
> messing with your brain, to see if you can summarize wads of code,
> deliberately contradictory statements, etc. :-) ]
Well, do so, let's see what I can take ;-)
Regards, David.
> Regards,
> Tim
>
> David Tanzer wrote:
> > Weldon Washburn, Geir Magnusson Jr. and I where discussing about the
> > programming language in which to implement harmony and the coding
> > conventions to use in the thread "[arch] Modular JVM component diagram".
> > I rewrote one of the interfaces Weldon wrote so it conforms to the Java
> > Coding Conventions (where possible - it is C code), which where only
> > cosmetic changes. Geir said his biggest concerns about coding
> > conventions is safety and clarity (and he gave some examples). There was
> > no decision yet.
> > [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL
> > PROTECTED]
> >
> > Alos in the thread "[arch] Modular JVM component diagram", Xiao-Feng Li,
> > Ron Braithwaite, Rodrigo Kumpera and Tom Tromey where discussing about
> > APR and POSIX as OS abstraction libraries. There is a wide agreement
> > that this makes sense. Tim Ellison then explained how the portability
> > library of the J9 VM (portlib) works and that it has some features which
> > APR doesn't have.
> > [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL
> > PROTECTED]
> >
> > Xiao-Feng Li started the thread "[arch] voluntary vs. preemptive
> > suspension of Java threads" where he explains both models and gives a
> > brief overview on the advantages and disadvantages of these approaches.
> > Kazuyuki Shudo and Rodrigo Kumpera posted some more information about
> > this topic.
> > [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL
> > PROTECTED]
> >
> > Rana Dasgupta started a discussion about "[arch] VM/Classlibrary
> > Interface ( VM Accessors )". He posted some initial thoughts about what
> > these accessors are ("They will provide access to VM functionality not
> > exposed through the public Java api"), how they could be implemented
> > (i.e. JNI) and which problems might occur (security, ...).
> > [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL
> > PROTECTED]
> >
> > Weldon Washburn was responding to a posting by Mladen Turk about
> > "light-weight native calls" where he lists some problems this approach
> > migth have and asks how Mladen wants to solve them. Steven Gong asked
> > how the VM/Classlibrary interface and VMAccessors are related, but he
> > has not received an answer yet.
> > [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL
> > PROTECTED]
> > [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL
> > PROTECTED]
> >
> > Regards, David.
> >
> > -- Read the archive of this series at http://deltalabs.at/
> > -- RSS feed: http://deltalabs.at/?q=taxonomy/term/8/0/feed
> >
>
--
David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe
http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net
My PGP Public Key: http://guglhupf.net/david/david.asc
--
Pinky, Are You Pondering What I'm Pondering?
I think so Brain, but if we have nothing to fear but fear itself,
then why does Elenor Roosevelt wear that spooky mask?
Re: This week on harmony-dev (Aug. 28 - Sept. 03 2005)
I think these summaries are great David, keep it up!
[ ...though it does make the little devil inside me want to start
messing with your brain, to see if you can summarize wads of code,
deliberately contradictory statements, etc. :-) ]
Regards,
Tim
David Tanzer wrote:
> Weldon Washburn, Geir Magnusson Jr. and I where discussing about the
> programming language in which to implement harmony and the coding
> conventions to use in the thread "[arch] Modular JVM component diagram".
> I rewrote one of the interfaces Weldon wrote so it conforms to the Java
> Coding Conventions (where possible - it is C code), which where only
> cosmetic changes. Geir said his biggest concerns about coding
> conventions is safety and clarity (and he gave some examples). There was
> no decision yet.
> [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL
> PROTECTED]
>
> Alos in the thread "[arch] Modular JVM component diagram", Xiao-Feng Li,
> Ron Braithwaite, Rodrigo Kumpera and Tom Tromey where discussing about
> APR and POSIX as OS abstraction libraries. There is a wide agreement
> that this makes sense. Tim Ellison then explained how the portability
> library of the J9 VM (portlib) works and that it has some features which
> APR doesn't have.
> [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL
> PROTECTED]
>
> Xiao-Feng Li started the thread "[arch] voluntary vs. preemptive
> suspension of Java threads" where he explains both models and gives a
> brief overview on the advantages and disadvantages of these approaches.
> Kazuyuki Shudo and Rodrigo Kumpera posted some more information about
> this topic.
> [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL
> PROTECTED]
>
> Rana Dasgupta started a discussion about "[arch] VM/Classlibrary
> Interface ( VM Accessors )". He posted some initial thoughts about what
> these accessors are ("They will provide access to VM functionality not
> exposed through the public Java api"), how they could be implemented
> (i.e. JNI) and which problems might occur (security, ...).
> [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL
> PROTECTED]
>
> Weldon Washburn was responding to a posting by Mladen Turk about
> "light-weight native calls" where he lists some problems this approach
> migth have and asks how Mladen wants to solve them. Steven Gong asked
> how the VM/Classlibrary interface and VMAccessors are related, but he
> has not received an answer yet.
> [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL
> PROTECTED]
> [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL
> PROTECTED]
>
> Regards, David.
>
> -- Read the archive of this series at http://deltalabs.at/
> -- RSS feed: http://deltalabs.at/?q=taxonomy/term/8/0/feed
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: [arch] VM/Classlibrary Interface (take 2)
Tim Ellison wrote: By the design, those kind of functions/methods will not be able to either allocate or throw java objects. Inlining doesn't impose any such restriction upon object creation. I know, but the point is that the overhead for calling that kind of native method should not require making a 'make a rocket launch procedure' :). Since those kind of 'light-weight' calls will lack the JNIEnv call argument, neither exceptions nor objects creation will be possible. Their sole purpose would be to extend the existing methods with native calls, leaving to the java part to deal with any kind of object creation. In general you may think of those calls simply as extension to the CPU machine code extensions, So are you proposing a light-weight call that has a restricted set of operations on heap memory, say to avoid allocations? Right. OTOH some calls can even be threated the same way as atomic calls to any CPU CISC like instruction (like array copy), thus blocking the GC. In that case the call to the native would be something like calling the 'synchronized method'. I'm puzzled again, calling a synchronized method won't block GC. Right, my bad. Any non atomic object passed to the call should be auto referenced, because the system call may block forcing a thread yield. All that would give the overall OS integration speedup for most of the standard classpath things, because instead throwing the exceptions from native, the java part of classpath would be responsible for that, leaving the native to behave like OS abstraction layer. While I don't think you'll see an overall classlibrary speedup by throwing exceptions in Java code rather than native code, I do think it is a good design point to write more of the classlibrary logic in Java rather than in native code. Today the JNI crossing overhead can impose a runtime cost that requires library logic to be written in natives that would have been better written in Java if the overhead were smaller. The problem is that when calling exiting native calls you have to 'prepare' the JVM for such a call. Since any JNI call can do almost any kind of either object usage or creation, that process makes most of the JNI calls that don't need such a option much slower. Writing as much classpath code inside Java and using light weight calls that don't require such a lengthy procedures before and after each call to the native would give much higher overall performance thought. Regards, Mladen.
Re: [arch] VM/Classlibrary Interface ( VM Accessors )
Hi Rana, Dasgupta, Rana wrote: > I would like to invite discussion and comments from the community on the > VM Accessor component in the Harmony Modular JVM diagram, on its > functionality, design and implementation. Here are some initial > thoughts. > > > > These are a helper set of singleton Java classes to support Classlibrary > implementation. We can instantiate them through an Accessor factory > interface ( Modular JVM diagram ). They will provide access to VM > functionality not exposed through the public Java api. So this is a "classlibrary developer's toolkit" ? I assume the goal is to allow implementation of classlibrary functionality in pure Java that currently has to be written using native code (assuming a C-based VM)? > Examples would be > object accessors( for direct get/set of object fields, object allocation > bypassing constructors, etc. ), array accessors ( to access arrays > bypassing bounds checks, manipulating GC on array types ), thread stack > accessors etc. Thoughts on how we define a complete list of VM accessor > classes? Your list appears to be a blend of operations that are functional enhancements and optimization enhancements. I expect that the functional enhancements would be discovered by need of the library implementors. The optimization enhancements would likey vary by VM/JIT implementor, with some requiring more 'hints' than others to generate good code. > How will we implement accessors in Harmony? An option could be using > JNI, and distributing/packaging VM accessors with the class library, but > there are performance problems associated with this. A proprietory > implementation tightly coupled to the VM could expose functionality in > the JIT or GC engine. This could potentially perform much better( be > inlinable by the JIT ), but how does that impact portability of the > accessor classes? I would expect such functionality to be VM-specific, and therefore part of the kernel classes provided by the VM-implementor. The question is how many accessors it is reasonable to expect such an implementor to be required to support in order to run the Harmony classlibraries. > We want to restrict access to the accessor functionality to the > Classlibrary, etc. One way to enforce this policy would be for the > accessor factory to check that the requesting class is on some white > list of classes before returning an accessor reference. Thoughts on > alternative schemes ? The problem with this scheme is that it requires everyone to follow the pattern. There is a risk that somebody may forget to check the list, or that a 'white' intermediary may pass-out a reference to someone who does not have rights to it directly. The componentization model discussed earlier would allow accessors to be in a separate component (which at least would prevent non-white code from ever referencing the accessors). > There seems to be an opportunity for an OpenSource programming model and > standardization of portions of the accessor api. My initial reaction is that we should use such functionality judiciously. Classlibrary code should be using public APIs wherever and whenever possible. The VMs' and JITs' optimization of public API will benefit both the classlibrary implementation and application code; and we don't want to be extending the language by the back door. Using VMAccessors will be predicated on a more robust security story and a fast Java<->VM interface. Regards, Tim > Thanks, > > > > Rana Dasgupta > > Intel Managed Runtime Development > > > > > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [arch] VM/Classlibrary Interface (take 2)
usman bashir wrote: > i am looking the same sort of things from IBM guys, as if i am not wrong > they claim to do same sort of things before :) > and it will really help full if we can have two baselines to work on. This would work better with a diagram, ... IBM has a set of class libraries (only a subset of SE) that have been independently developed, i.e. based on the spec. These are designed to be portable across VM implementations but have been principally written against J9. Other VMs can run the class library by implementing the JNI + VMI interface. Here "the VM" is defined as the interpreter etc. _plus_ a core set of kernel classes. This structure has already been described here [1]. The class library natives and J9 VM in turn go through the port layer to the OS. I described the port lib briefly here [2]. Apart from 'portability', the port lib structure gives a degree of isolation and control over VM instances by associating resource use with a particular VM instance. Regards, Tim [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200507.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] > On 8/29/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >>And on the wiki after posting here, please? :) >> >>geir >> >>On Aug 19, 2005, at 12:33 PM, Tim Ellison wrote: >> >> >>>Weldon Washburn wrote: >>> >>> On 7/11/05, Tim Ellison <[EMAIL PROTECTED]> wrote: >Recently, within IBM, we have been defining the interface between >IBM's >class library and the J9 VM. We deliberately haven't looked at >the GNU >Classpath/VM interface specification. > >The principal goals are to enable the class libraries to be >hosted on >different versions of a virtual machine, and potentially different >virtual machines, without sacrificing performance or introducing >complexity. In our design, this results in a number of class types >being (architecturally) labeled as 'kernel classes'. Kernel >classes can >be thought of as part of the VM and have to be written by the >VM-provider. With a thoughtful set of kernel classes the API >from class >library to the VM, and from VM to class libraries, can be kept >remarkably small. Our complete VM/Classlibrary interface >comprises a >short C header (vmi.h), about 18 classes defined by 1.4 public API >(java.lang, java.lang.reflect, ...), and two classes that are >specifically to support the interface. We are working on necessary >extensions to this interface for 1.5. > >If there is an interest, we can share the interface we are using and >evolve it as part of harmony. > Tim, It would be good if you would go ahead and post the VM/Classlibrary interface you describe above on harmony wiki. Thanks Weldon >>> >>>I'm just about to leave for a week's vacation, so rather than post and >>>then disappear, I'll wait until I get back and can engage in proper >>>discussion. >>> >>>Regards, >>>Tim >>> >>> >>> >It would be great if we could share >experiences with the GNU Classpath VM interface in such a way >that the >Harmony interface was suitable for the widest variety of VMs and >class >libraries. > >Regards, >Tim > >-- > >Tim Ellison ([EMAIL PROTECTED]) >IBM Java technology centre, UK. > > > >>>-- >>> >>>Tim Ellison ([EMAIL PROTECTED]) >>>IBM Java technology centre, UK. >>> >>> >> >>-- >>Geir Magnusson Jr +1-203-665-6437 >>[EMAIL PROTECTED] >> >> >> > > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [arch] VM/Classlibrary Interface (take 2)
Mladen Turk wrote: > Weldon Washburn wrote: > >> Hi Mladen, >> I am curious about 'light-weight' native calls for primitive array >> type you mentioned below. In the general case, a GC might move the >> primitive array while the native method is operating on the array. Can >> you tell us how the light-weight interface would deal with this >> situation? Does the array need to be pinned before calling the >> light-weight native? > > > Well, those kind of things are exactly the one that need to be resolved. > With light-weight (or what ever we name them) calls, the call to the > native should not differ from calling any other inlined method, and thus > by that bare fact the GC itself would be treated the same way when the > any Java method is called. I'm trying to reconcile the similarities you draw between a light-weight native call and any inlined method? > By the design, those kind of functions/methods will not be able > to either allocate or throw java objects. Inlining doesn't impose any such restriction upon object creation. > Their sole purpose would be to extend the existing methods with > native calls, leaving to the java part to deal with any kind of > object creation. In general you may think of those calls simply > as extension to the CPU machine code extensions, So are you proposing a light-weight call that has a restricted set of operations on heap memory, say to avoid allocations? > but since they > may be a long run, for primitive array access > (by that I mean accessing the raw storage locations inside JVM), > the reference count should take place if required. Of course, a reader and writer of heap memory has to be aware of GC too. It would have to prevent or account for memory movement. > OTOH some calls can even be threated the same way as atomic calls > to any CPU CISC like instruction (like array copy), thus blocking > the GC. In that case the call to the native would be something > like calling the 'synchronized method'. I'm puzzled again, calling a synchronized method won't block GC. > All that would give the overall OS integration speedup for most of > the standard classpath things, because instead throwing the exceptions > from native, the java part of classpath would be responsible for that, > leaving the native to behave like OS abstraction layer. While I don't think you'll see an overall classlibrary speedup by throwing exceptions in Java code rather than native code, I do think it is a good design point to write more of the classlibrary logic in Java rather than in native code. Today the JNI crossing overhead can impose a runtime cost that requires library logic to be written in natives that would have been better written in Java if the overhead were smaller. Regards, Tim > Regards, > Mladen. > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
