Re: OPEN Specification
First a caveat that I have only read the OPEN document through quickly so far, so apologies if this is off-base. I do intend to go back an read more thoroughly. Is it fair to generalize the Accessors proposal to say that there should be internal APIs in the 'right place' within the class library to allow a good range of OS/CPU/VM architectures to optimize their implementation? The document describes some ideas about how the optimizations will occur (singleton classes, JIT recognized methods, etc.) but I just want to back-up a moment to check the rationale before looking at the solution. Regards, Tim Rana Dasgupta wrote: > Hi Andrew, > Thanks for your comments and interesting feedback. The ideas in this spec > are certainly open to debate and input from everyone. As we well know, > modularity is a great goal which has many merits...testability, ease of > development, plug and play etc. However it is less easy to achieve in a > pure > form...some degree of pollution creeps into an implementation when one > tries > to optimize on other goals like performance, footprint etc. I was hoping > that we could see this submission as a strawman for how one could > potentially modularize VM development. With input from knowledgeable people > in the community, maybe a standard for modular VM development can evolve > out > of this... > >For context, this proposal sees the accessor( platform and VM > ) mechanism as a tool to facilitate Classlibrary development in Java( as > you > obeserved below ). They are a set of singleton classes that class libraries > instantiate securely through a factory mechanism. Their implementation is > provided by the VM. Their default fully portable implementation could be > via > JNI, however there is potential for performance optimization...eg., once > instantiated, the per invocation security could be relaxed, the JIT could > recognize and aggressively inline them, etc. > I have tried to answer some more of your questions inline > >> I wonder who has the responsibility to provide such native-related and >> platform-independent interfaces to java classlib programmer? >> ...Then shall classlib programmer write native code to implement >> high-level > functions such as >> "findFirstDiff" and invoke them via JNI mode? or shall VM provide such >> high-level functions and classlib programmer only need call >> mem.findFirst? > > > These are VM components. The idea is that the VM provides them and the > Classlib programmer writes less native code. > >> As my understanding of the document, classlib programmer will avoid >> writing >> native code directly, and invoke corresponding interfaces defined in VM. > > That is correct > >> If I'm right, I think it's very hard for VM to provide so many > native-related >> APIs for classlib programmer. For example, java.net.Socket >> implementation. > Classlib >programmer still has to write native code to implement Socket > function. And I also think it's >> classlib programmer's responsibility > > The idea is that the VM provides some standardized functionality through VM > and Platform accessors. How much that is, is part of the standard > definition > that we need. I am not completely sure what you mean by the "classlib > programmer's responsibility". It is true that the classlib programmer will > need to implement whatever is not provided by the standardised accessor > components. > > Thanks, > Rana > > On 5/12/06, Andrew Zhang <[EMAIL PROTECTED]> wrote: >> >> Hello, Rana >> >> I took a quick view on the document, and I have some questions on Chapter >> 6. >> >> Let's take 6.9.1 "A.NM ACCESS TO NATIVE MEMORY" as example: >> >> The MemoryAccessor interface includes the following function >> groups: >> 1.Memory allocation and de-allocation: malloc, realloc, free >> 2.Operations over primitive types: getByte, getDouble,setBoolean >> 3.Operations over arrays of primitive types: getChar(char[] buf,..) >> 4.Search operations: findFirstDiff, findFirstDiffReorder >> >> For full description, please refer to " >> http://issues.apache.org/jira/browse/HARMONY-459"; or [1]. >> >> I wonder who has the responsibility to provide such native-related and >> platform-independent interfaces to java classlib programmer? >> >> No doubt "OS Portability Layer" provides platform-independent interfaces, >> e.g, portable_malloc or portable_free. Then shall classlib >> programmer write native code to implement high-level functions such as >> "findFirstDiff" and invoke them via JNI mode? or shall VM provide such >> high-level functions and classlib programmer only need call >> mem.findFirst? >> >> I think Harmony classlib follows the former way currently. >> As my understanding of the document, classlib programmer will avoid >> writing >> native code directly, and invoke corresponding interfaces defined in VM. >> If >> I'm right, I think it's very hard for VM to provide so many >> native-related >> >> APIs for classlib programmer. >> For example, java.net.
Re: Supporting working on a single module?
Andrey Chernyshev wrote: > (1) Do we need to keep the 'main' directory in every module? If we > need to have a distinction between tests and sources, may be just pull > tests one level up and have something like: > archive/ >src/ > native/ > java/ > tests/ > native/ > java/ > I wonder if 'main' is an extra level of the directory tree we can > actually avoid of (lazy people don't like typing cd too much :)) Really lazy people use path completion and don't care ;-) > (2) Why do we need to have 'luni' two times in the path, e.g. > modules/luni/src/main/native/luni/ ? If we need to put an additional > stuff like 'port' to the luni module, perhaps it could be just enough > to put it into a subdirectory within native, e.g: > modules/luni/src/native/port/ ? Is it just the name of that path element that you object to? Seems a bit cleaner to me if there is a bucket to put that source in. However, (comment to Oliver as well), I'm left wondering where the platform-specific vs. common code distinction is made? > BTW, I've noticed that this proposal is very similar to the DRLVM > source tree organization, which is like: Great minds and all that :-) > - vm >- include - top level include which contains h files exported by > various VM components; >- interpreter >- jitrino >- vmcore >... > > > The module vmcore, for example, contains both native and java code: > vmcore/src/kernel_classes > - native > - javasrc > > The building system for DRLVM has been designed in a modular way as well: > There is a "building engine part at the build/make and > build/make/targets directory which is shared by all components, > Each VM module has a building descriptor which is currently located at > build/make/components directory, but can also be easily moved to the > component source tree to support the idea of full independent checkout > of a specific module. > > I think the building system provided with DRLVM can easily be used to > support the source modularization approach, the proposed 'hdk' in that > case would provide the developers, besides the "public includes", with > the shared part of the building scripts as well. We should continue to collaborate on finding the best solution -- it has worked very well so far! Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Request for golden ticket to update String class (was: Re: [classlib] Exception throwing compatibility)
I agree with your analysis. +1 from me.
Regards,
Tim
Stepan Mishura wrote:
> On 5/12/06, *Jimmy, Jing Lv* wrote:
>
>
> >> In this case, though replace StringIndexOutOfBoundsException with
> >> ArrayIndexOutOfBoundsException is surely better, it seems it is
> internal
> >> implementation what cause the problem. According to the code it use
> >> String.valueof(str), which writes:
> >> try {
> >>System.arraycopy(data, start, value, 0, count);
> >> } catch (IndexOutOfBoundsException e) {
> >>throw new StringIndexOutOfBoundsException();
> >> }
> >
> >
> > IMHO this try-catch block is redandunt - the method code already
> contains
> > checks to verify that all parameters are valid:
> > if (start >= 0 && 0 <= length && length <= data.length - start) {
> >
> > else
> >throw new StringIndexOutOfBoundsException();
> >
>
> I believe you are right, but there may be some reasons for the author
> to write such try{...}catch(){}, perhaps he do follow RI's exception in
> the class String.
>
>
> Hi,
>
> I'd like to acquire golden ticket for updating String.java file. Please
> review my request.
>
> Description:
> Constructor: public String(char[] data, int start, int length) contains
> redundant try-catch block that should be removed:
> try {
> System.arraycopy(data, start, value, 0, count);
> } catch (IndexOutOfBoundsException e) {
> throw new StringIndexOutOfBoundsException();
> }
>
> Basis:
> According to the spec. method
> System.arraycopy(Object src, int srcPos, Object dest, int destPos, int
> length)
>
> throws IndexOutOfBoundsException in the following cases:
> 1) srcPos < 0
> 2) destPos < 0
> 3) length <0
> 4) srcPos+length > src.length
> 5) destPos+length > dest.length
>
> In our case: destPos is passed as 0 value and dest array is allocated
> as: value = new char[length]. So in 2 and 5 cases IOOBE cannot be thrown
> by arraycopy method. For other cases (1,3,4) the constructor contains
> explicit check and throws SIOOBE if passed parameters are invalid:
> if (start >= 0 && 0 <= length && length <= data.length - start) {
>
> } else {
> throw new StringIndexOutOfBoundsException();
>
> So System.arraycopy(...) method MUST not throw IOOBE in the the
> constructor and try-catch block is redundant in this case.
>
> Patch file is attached.
>
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
> --
> Terms of use : http://incubator.apache.org/harmony/mailing.html
>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
>
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
> Index: modules/luni/src/main/java/java/lang/String.java
> ===
> --- modules/luni/src/main/java/java/lang/String.java (revision 405602)
> +++ modules/luni/src/main/java/java/lang/String.java (working copy)
> @@ -434,11 +434,8 @@
> offset = 0;
> value = new char[length];
> count = length;
> - try {
> - System.arraycopy(data, start, value, 0, count);
> - } catch (IndexOutOfBoundsException e) {
> - throw new StringIndexOutOfBoundsException();
> - }
> +
> + System.arraycopy(data, start, value, 0, count);
> } else
> throw new StringIndexOutOfBoundsException();
> }
>
>
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: OPEN Specification
Hi Andrew, Thanks for your comments and interesting feedback. The ideas in this spec are certainly open to debate and input from everyone. As we well know, modularity is a great goal which has many merits...testability, ease of development, plug and play etc. However it is less easy to achieve in a pure form...some degree of pollution creeps into an implementation when one tries to optimize on other goals like performance, footprint etc. I was hoping that we could see this submission as a strawman for how one could potentially modularize VM development. With input from knowledgeable people in the community, maybe a standard for modular VM development can evolve out of this... For context, this proposal sees the accessor( platform and VM ) mechanism as a tool to facilitate Classlibrary development in Java( as you obeserved below ). They are a set of singleton classes that class libraries instantiate securely through a factory mechanism. Their implementation is provided by the VM. Their default fully portable implementation could be via JNI, however there is potential for performance optimization...eg., once instantiated, the per invocation security could be relaxed, the JIT could recognize and aggressively inline them, etc. I have tried to answer some more of your questions inline I wonder who has the responsibility to provide such native-related and platform-independent interfaces to java classlib programmer? ...Then shall classlib programmer write native code to implement high-level functions such as "findFirstDiff" and invoke them via JNI mode? or shall VM provide such high-level functions and classlib programmer only need call mem.findFirst? These are VM components. The idea is that the VM provides them and the Classlib programmer writes less native code. As my understanding of the document, classlib programmer will avoid writing native code directly, and invoke corresponding interfaces defined in VM. That is correct If I'm right, I think it's very hard for VM to provide so many native-related APIs for classlib programmer. For example, java.net.Socket implementation. Classlib >programmer still has to write native code to implement Socket function. And I also think it's classlib programmer's responsibility The idea is that the VM provides some standardized functionality through VM and Platform accessors. How much that is, is part of the standard definition that we need. I am not completely sure what you mean by the "classlib programmer's responsibility". It is true that the classlib programmer will need to implement whatever is not provided by the standardised accessor components. Thanks, Rana On 5/12/06, Andrew Zhang <[EMAIL PROTECTED]> wrote: Hello, Rana I took a quick view on the document, and I have some questions on Chapter 6. Let's take 6.9.1 "A.NM ACCESS TO NATIVE MEMORY" as example: The MemoryAccessor interface includes the following function groups: 1.Memory allocation and de-allocation: malloc, realloc, free 2.Operations over primitive types: getByte, getDouble,setBoolean 3.Operations over arrays of primitive types: getChar(char[] buf,..) 4.Search operations: findFirstDiff, findFirstDiffReorder For full description, please refer to " http://issues.apache.org/jira/browse/HARMONY-459"; or [1]. I wonder who has the responsibility to provide such native-related and platform-independent interfaces to java classlib programmer? No doubt "OS Portability Layer" provides platform-independent interfaces, e.g, portable_malloc or portable_free. Then shall classlib programmer write native code to implement high-level functions such as "findFirstDiff" and invoke them via JNI mode? or shall VM provide such high-level functions and classlib programmer only need call mem.findFirst? I think Harmony classlib follows the former way currently. As my understanding of the document, classlib programmer will avoid writing native code directly, and invoke corresponding interfaces defined in VM. If I'm right, I think it's very hard for VM to provide so many native-related APIs for classlib programmer. For example, java.net.Socket implementation. Classlib programmer still has to write native code to implement Socket function. And I also think it's classlib programmer's responsibility. I don't know whether OPEN spec would plan to provide such interfaces? IMO, ByteBuffer example and Socket example is on the same level programming, and the real implemenation native code should exist on the same level code repository, e.g, both in VM or classlib native-src. Am I missing something? Would anyone clarify my confusion? Thanks a lot! [1] The java.nio package defines the buffer classes, which are used throughout the native input and output (NIO) APIs. Buffers can be *direct* or * non-direct*. Given a direct buffer, the system performs native I/O operations directly without copying the buffer content from the native to the Java* layer, Java*arrays. A direct byte buffer is created by us
jchevm status?
I have recently built jchevm and tried to run eclipse with it. When loading a error window appeared. It looks like a bug or unimplemented functionality. I have taken a look at list of loaded native libraries. It looks classpath is used for system classes instead of harmony classlib. I remember, there was some discussion about porting jchevm to harmony classlib, what is the status of this work? Harmony classes prooved to work in drlvm. So I think once the porting is done it could be possible to get eclipse working on jchevm soon. -- Ivan Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] exception messages
Hello, Mikhail
org.apache.harmony.luni.util.Msg has already handled locale issue.
So it's not neccessary to get locale inforamtion again in test case, and
then get i18n message.
For example, following code is from java.net.HttpURLConnection.java
method setRequestMethod:
if (connected)
throw new ProtocolException(org.apache.harmony.luni.util.Msg.getString
("K0037"));
Correspondingly, we could write a test case:
public void test_setRequestMethod(){
try{
... // make the exception happen
}catch(ProtocolException e){
assertEquals(Msg.getString("K0037"), e.getMessage());
}
Since source code and test code are running in the same runtime, they use
the same locale information, which is used to initialize ResourceBundle in
class Msg.
static {
// Attempt to load the messages.
try {
bundle = MsgHelp.setLocale(Locale.getDefault(),
"org.apache.harmony.luni.util.ExternalMessages");
}
...
}
Finally, I don't think we need test exception message in most cases,
unless there're some speical reasons, e.g, the exception message format is
metioned in spec.
Any comment? Thanks!
On 5/13/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
Another (more preferable for me) way could be set a specific locale and
compare to the message for this locale
Thanks,
Mikhail.
2006/5/13, Andrew Zhang <[EMAIL PROTECTED]>:
> Hello,
>
> If we really decide to test exception message, I think we could write
test
> case as follows:
>
> public void test_f(){
>.
>catch(SomeException e){
> assertEquals(org.apache.util.Msg.getString("K508C"),e.getMessage
> ());
>}
> }
>
> Does it work? Because what we want to make sure it that "SomeException"
is
> really thrown with message K508C. So that's another reason that we
should
> use Msg.getString rather than explicit string to fill exception
> information.
>
> On 5/13/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> >
> > Loenko, Mikhail Y wrote:
> > > From: Tim Ellison [mailto:[EMAIL PROTECTED]
> > >> So let me refine my position to say, "our API tests shouldn't be
> > >> asserting the value of unspecified parts of an exception message".
> > >> Does that make sense?
> > >
> > > Yes, it does. But we might have impl tests that check for exception
> > > messages.
> >
> > Ok, provided they still pass when I translate the message catalog to
> > Klingon ;-)
> >
> > Regards,
> > Tim
> >
> > --
> >
> > Tim Ellison ([EMAIL PROTECTED])
> > IBM Java technology centre, UK.
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Andrew Zhang
> China Software Development Lab, IBM
>
>
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrew Zhang
China Software Development Lab, IBM
Re: [admin] contrib policy
Tim Ellison wrote: (Apologies if your note was not directed to me...) Magnusson, Geir wrote: Is any license included? Nope, no license file and no block comments in the source files (that I checked). If not, just add that Not my prerogative to license Alexander's code :-) I didn't mean you :) I'll put pointers on the wiki that our mail list contribution policy applies... Sure, but IMHO anything other than code snippets should come in via JIRA with the definitive grant so we know exactly what we got when and can solicit ACQs etc. Yes. To make that clearer - anything we want to accept into the SVN (snippet or snippet++) should come in through JIRA. For the chalkboard^H^H^H^H^H^H^H^H^H wiki, we do need to make the terms of 'contribution' and participation clear... (We ran into the same issue recently in G...) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[admin] contrib policy (was: Re: Stress tests generator)
(Apologies if your note was not directed to me...) Magnusson, Geir wrote: > Is any license included? Nope, no license file and no block comments in the source files (that I checked). > If not, just add that Not my prerogative to license Alexander's code :-) > I'll put pointers on the wiki that our mail list contribution policy > applies... Sure, but IMHO anything other than code snippets should come in via JIRA with the definitive grant so we know exactly what we got when and can solicit ACQs etc. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] -- JVMTI support?
On Saturday 13 May 2006 02:53 Elford, Chris L wrote: > I'll need to look at this a bit more closely. Some of the > CompiledMethodLoad data for secondary jit events look a bit strange. It > sounds like support is still early so this type of issue will likely be > resolved as the VM and JIT evolve? > > For example, for > org.eclipse.osgi.framework.internal.core.KeyedHashSet.getByKey(Ljava/lan > g/Object;)Lorg/eclipse/osgi/framework/internal/core/KeyedElement; > > I see three CompiledMethodLoad events. > > VALength Time > 0x00D196C0 0x039A 05/12-15:25:21 > 0x0B2D6D10 0x021C 05/12-15:25:41 > 0x00D196C0 0x039A 05/12-15:25:41 > > It looks like the method is jitted once then 20 seconds later it is > rejitted to a new address [and made smaller] then is immediately > rejitted back to its original location and size. Hello Chris. I think I know what is happening. It is just a guess since I don't know the details of recompilation, but this guess explains this strange behavior. Each method may have multiple code chunks, some compiled with the same JITs, other compiled with different ones. When recompilation happens the new chunks are added to the list of code chunks of the method. Since JVMTI doesn't really know what chunks were reported already and which were not, it reports all of them every time a method is compiled. So for the second time you see both new and old code. This is probably not very convenient but that's how it currently works. I think it is a bug and before compilation is done JVMTI has to remember all code chunks that are already present in the method and then report only new ones. Maybe there is an easier way to distinguis between old and new code chunks, I'll have to look closer at the code. > -Original Message- > From: Gregory Shimansky [mailto:[EMAIL PROTECTED] > Sent: Friday, May 12, 2006 3:08 PM > To: harmony-dev@incubator.apache.org > Subject: Re: [DRLVM] -- JVMTI support? > > On Friday 12 May 2006 22:18 Elford, Chris L wrote: > > Hi all, > > > > I was working with the version of DRLVM that I compiled off of > > JIRA-438. I tried it with a JVMTI agent using -agentlib:... It looks > > like this version gives Class Load events. According to JVMTI, > > loading > > > eclipse loads 4,189 classes. > > > > I'm not seeing any Method Load Events though. Has anyone else tried > > JIRA-438 with JVMTI and seen more events? > > If you mean CompiledMethodLoad event, you may not see it since when > JVMTI is > enabled on command line (-agentlib, -agentpath or -xrun options are > specified) then by defaul VM currently enables interpreter mode. It is > made > because JVMTI is not implemented to any usable extent in VM in JIT mode > yet. > But in interpreter mode it is already usable for simple debugging. > > So if you want to see CompiledMethodLoad event you need to explicitly > specify > -Dvm.use_interpreter=false on the VM command line. This will allow you > to > receive some JIT/interpreter independent events like ClassLoad or > ClassPrepare and several profiling related events like > CompiledMethodLoad or > DynamicCodeGenerated. If that doesn't work, let me know. It should :) -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] exception messages
Another (more preferable for me) way could be set a specific locale and
compare to the message for this locale
Thanks,
Mikhail.
2006/5/13, Andrew Zhang <[EMAIL PROTECTED]>:
Hello,
If we really decide to test exception message, I think we could write test
case as follows:
public void test_f(){
.
catch(SomeException e){
assertEquals(org.apache.util.Msg.getString("K508C"),e.getMessage
());
}
}
Does it work? Because what we want to make sure it that "SomeException" is
really thrown with message K508C. So that's another reason that we should
use Msg.getString rather than explicit string to fill exception
information.
On 5/13/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>
> Loenko, Mikhail Y wrote:
> > From: Tim Ellison [mailto:[EMAIL PROTECTED]
> >> So let me refine my position to say, "our API tests shouldn't be
> >> asserting the value of unspecified parts of an exception message".
> >> Does that make sense?
> >
> > Yes, it does. But we might have impl tests that check for exception
> > messages.
>
> Ok, provided they still pass when I translate the message catalog to
> Klingon ;-)
>
> Regards,
> Tim
>
> --
>
> Tim Ellison ([EMAIL PROTECTED])
> IBM Java technology centre, UK.
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Andrew Zhang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
