Re: OPEN Specification
Etienne, I didn't mean that every Harmony JVM should follow OPEN interface. It is not necessary to implement but maybe JVMs can benefit from following it (or any kind of standard interface accepted by the community). It is just a proposal with some simple ideas behind it: First, JVM should be modular. Second, those modules should have standard interfaces (and therefore, be reusable in other VMs). If you don't agree with this approach or have any other thoughts about the proposal - please share it with the community - your opinion and your experience is valuable. I believe this document was made so large not with the intention that nobody would read it but just because of the complexity of problem and an attempt to clarify all issues :) -- Regards, Anton Luht, Intel Middleware Products Division On 5/29/06, Etienne Gagnon [EMAIL PROTECTED] wrote: Hi Anton, Are you proposing that all Harmony JVMs must abide by the OPEN proposal? If yes, I think that some process has to be put in place to present and discuss each of this proposal's part, and dedicate time to do so. IMO, I don't think that everyone (in the JVM sub-communityof Harmony) can simply read through this proposal and be able to make an enlightened decision about it. I think that each point would gain much from being presented along the motivation behind it. For example, would your OPEN proposal work with a bidirectional object layout, without incurring prohivitive performance costs? [Just asking, I didn't have time to read through all of it...] Of course, this is only an opinion. :-) Etienne Anton Luht wrote: Hello, I would like to try to draw attention to the OPEN proposal again. It was published about two weeks ago and produced a very small response in the community. This interface is very important, because if it is accepted, it will become a base of (many?) Harmony VMs. For example, one of the current limitations of OPEN interfaces is that Component Manager loads all components at startup and there's no possibility to change a component (for example, Garbage Collector) later. Is it OK for everyone? Maybe someone foresees problems with such approach? -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Acceptance of HARMONY-438 : DRL Virtual Machine Contribution
+1 -Mark On 30 May 2006 at 20:06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I have received the ACQs and the BCC for Harmony-438, so I can assert that the critical provenance paperwork is in order and in SVN. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. I think that getting this into SVN and letting people supply patches against SVN will be productive... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Acceptance of HARMONY-438 : DRL Virtual Machine Contribution
+ 1 I have received the ACQs and the BCC for Harmony-438, so I can assert that the critical provenance paperwork is in order and in SVN. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. I think that getting this into SVN and letting people supply patches against SVN will be productive... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Acceptance of HARMONY-438 : DRL Virtual Machine Contribution
+1 Geir Magnusson Jr wrote: I have received the ACQs and the BCC for Harmony-438, so I can assert that the critical provenance paperwork is in order and in SVN. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. I think that getting this into SVN and letting people supply patches against SVN will be productive... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - 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] internationalization (was: Re: svn commit: r407780 - in /incubator/harmony/enhanced/classlib/trunk/modules/archive/src: main/java/java/util/jar/Attributes.java test/java/org/apache/harm
2006/5/25, Tim Ellison [EMAIL PROTECTED]:
Mikhail Loenko wrote:
We also agreed to put only internationalized messages and
to have a single catalog by module.
Yep, that's a good task for somebody who is looking for a simple way to
contribute to Harmony's classlibs.
If anyone wants to volunteer then go for it -- I can help with guidance
if required.
Is there any way to meet all the agreements without rewriting the
internationalization framework?
I don't think we need to change the mechanism we use to get message
strings from resource catalogs, just split the single catalog up across
the modules.
So we are splitting messages across the modules and than unite them back
at build time, correct?
Thanks,
Mikhail
Regards,
Tim
2006/5/19, Magnusson, Geir [EMAIL PROTECTED]:
And if we didn't, I think we just did :)
--
Geir Magnusson Jr
SSG/MPD
[EMAIL PROTECTED]
+1 203 665 6437
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Friday, May 19, 2006 7:03 AM
To: harmony-dev@incubator.apache.org
Subject: Re: svn commit: r407780 - in
/incubator/harmony/enhanced/classlib/trunk/modules/archive/src
: main/java/java/util/jar/Attributes.java
test/java/org/apache/harmony/archive/tests/java/util/jar/Attri
butesTest.java
[EMAIL PROTECTED] wrote:
snip
public void putAll(Map attrib) {
+if( attrib == null ) {
+throw new ClassCastException();
+}
Shouldn't this have a message? I thought we agreed that we'd
add useful
messages to exceptions.
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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Acceptance of HARMONY-438 : DRL Virtual Machine Contribution
+1 Geir Magnusson Jr wrote: I have received the ACQs and the BCC for Harmony-438, so I can assert that the critical provenance paperwork is in order and in SVN. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. I think that getting this into SVN and letting people supply patches against SVN will be productive... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang 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]
Re: [classlib] internationalization
Mikhail Loenko wrote: 2006/5/25, Tim Ellison [EMAIL PROTECTED]: Mikhail Loenko wrote: We also agreed to put only internationalized messages and to have a single catalog by module. Yep, that's a good task for somebody who is looking for a simple way to contribute to Harmony's classlibs. If anyone wants to volunteer then go for it -- I can help with guidance if required. Is there any way to meet all the agreements without rewriting the internationalization framework? I don't think we need to change the mechanism we use to get message strings from resource catalogs, just split the single catalog up across the modules. So we are splitting messages across the modules and than unite them back at build time, correct? Sorry for causing confusion, I was being too brief. I meant that the mechanism we currently have in LUNI (i.e. a resource file of externalized strings and a helper class like Msg to load the string and format it etc.) can be duplicated in each module that has externalized strings e.g. for exception messages. Of course, each module would only have its own messages. In this case the code is quite trivial so I don't see a big problem with duplication. At runtime, each module is a self-contained JAR with it's o.a.h.foo.internal.Msg and string catalog in the JAR file. 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: JSSE provider contribution
great, thanks Boris. Tim Boris Kuznetsov wrote: Dear all, I would like to announce one more contribution to Harmony on behalf of Intel. The archive with the contribution is uploaded to the following location: http://issues.apache.org/jira/browse/HARMONY-536 This contribution contains the implementation of the JSSE service provider for x-net component. The Java* Secure Socket Extension (JSSE) service provider enables secure Internet communications. The code is a result of efforts of Intel Middleware Product Division team. All code is pure Java. The implementation is done according to Java 1.5, TLS v1.0 and SSL v3 protocol specifications. The implementation uses available crypto algorithms provided by some crypto provider (e.g. BC provider). The archive contains the README file that explains the things doable with this code. But, should any additional clarifications be required, I'll be happy to provide them. You are welcome to try it out! Thank you, Boris Kuznetsov 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] -- 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] millions of rmi tests
Hi,
Just like to pay your attention on JUnit best practices concerning
this topic (in case if you are talking about UNIT tests):
http://junit.sourceforge.net/doc/faq/faq.htm#best_2
Especially paragraphs two and three.
2006/5/31, Mikhail Loenko [EMAIL PROTECTED]:
Hi Daniel,
I think what we need is tests that verify that our implementation works
according to our design.
As I understand the design for that constructor is as follows: store all
parameters in private fields and don't do any special for special parameters.
That means that we need just two test methods:
- test that passes 'normal' parameters to the constructor and verifies
private fields
by getXX methods (or with access to internal stuff)
- test that passes 'suspicious' values for all the parameters and verifies that
no exception thrown and private fields are set as expected.
The broad testing you've mentioned does make much sense on design stage:
e.g. if the spec is not clear enough you might want to do a black-box
testing of RI.
For example, for an integer parameter of a method you might want to go
through all the integer values and explore how it works on RI.
But once you explored it and found that e.g. it works this way for all positive
values and that way for all negative values and zero, you do an
appropriate design
and include a small number of unit tests to the test suite (like passing
0, 1, -1, 10, 10, minvalue, maxvalue, couple more). You don't have to
include all the tests that you used for design.
Please let me know what you think
Thanks,
Mikhail
2006/5/30, Daniel Gandara [EMAIL PROTECTED]:
Mikhail,
Let me explain the reasons why we developed this amount of tests;
We decided to develop implementation independant tests cases which
will show if a given implementation of the package behaves as it should
(RI); we also decided to implement them at the same time the package
was being coded, so no implementation specific detail was known by
the time the tests were developed.
In order to do this we developed:
- Unit tests: for them we took different approachs, which were:
- broad tests: where we test each public method with a set of
possible inputs
- specific tests: using 'suspicious' parameters like null
unit tests were developed using a mix of automatic code generation
and regular coding.
- Integration tests: http tunneling and distributed integration tests
which provide a more realistic and smart test for the package.
All this tests allowed us to check the correct functionality of our
package.
That said, I will agree with you that at this moment some of this tests
(mostly basic JUnit tests) might not be very usefull, and I would add
that more and complex integration tests should be written to check
the correct functionality of rmi package.
At this moment we are running all tests (both itc and intel) against
contributed rmi packages (both itc and intel); I'll send the report as
soon as I have it.
Thanks,
Daniel
note: latest tests source code and doc can be found at
http://issues.apache.org/jira/browse/HARMONY-473
btw: there were not millions but a few thousands tests :)
- Original Message -
From: Mikhail Loenko [EMAIL PROTECTED]
To: harmony-dev@incubator.apache.org
Sent: Monday, May 29, 2006 10:01 AM
Subject: [classlib] millions of rmi tests
I've tried to integrate rmi2 tests to rmi module, and found some odd
things.
Let's take a look for example at TestActivationGroupDesc.java
it has 5158 test methods, most of which are very similar.
For example it has 855 tests that invoke constructor with various parameters
and check that new did not return null and no exception was thrown:
Compare
public void
testActivationGroupDescStringStringMarshalledObjectPropertiesCommandEnvironment006()
{
try{
Properties p= new Properties();
assertNotNull(msgNotNull, new ActivationGroupDesc(null , null ,
new MarshalledObject(new Double(23.4)) , new Properties()
,
new ActivationGroupDesc.CommandEnvironment(Hola la,
new String[0])));
} catch (Throwable e) {
fail(msgNoException+e);
}
}
and
public void
testActivationGroupDescStringStringMarshalledObjectPropertiesCommandEnvironment007()
{
try{
Properties p= new Properties();
assertNotNull(msgNotNull, new ActivationGroupDesc(null , null ,
new MarshalledObject(new Double(23.4)) , new Properties()
,
new ActivationGroupDesc.CommandEnvironment(, null)));
} catch (Throwable e) {
fail(msgNoException+e);
}
}
This is how the constructor under test looks like:
public ActivationGroupDesc(String className, String codebase,
MarshalledObject data, Properties props,
ActivationGroupDesc.CommandEnvironment env) {
this.className = className;
this.location = codebase;
this.data =
Re: [classlib] millions of rmi tests
Mikhail Loenko wrote: 2006/5/30, Geir Magnusson Jr [EMAIL PROTECTED]: Mikhail Loenko wrote: It seems that instead of those million test cases we need just a few that would verify that getXXX() methods return what was passed into constructor plus possibly some tests that pass 'suspicious' parameters like null. Thoughts? I don't agree that would be enough - having tests that assualt the CTORs w/ combinations of crap to see what happens isn't a bad thing. Not a fun thing to write, but certainly not something I vote on throwing away if someone wrote it already. They were not written, they were generated. And I suspect that if we change some options to test generator then it can generate as many tests as you have free space on your hard drive. Do we need them all in the test suite? My question is given that so far we had ~7500 tests against all the API do we need 5000+ tests against a single trivial constructor? Are there really 5000+ tests against *one* CTOR? Why do you see a problem? The problem is test execution time. Then pitch what you think isn't needed. shrug Any other thoughts? I think that it's misleading to trust only that getters return what's passed in... Sorry, I did not catch I mean that you had suggested that we'd be ok by testing to see if getters (getXxxx()) returned what was passed into a CTOR correctly, and I thought that wasn't a safe assumption. geir - 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] logging from within our implementation
Chris Gray wrote: It's probably also not a good idea to rely too much on JIT optimisations, given that Harmony should run on a number of VMs and not all of these will have a fully optimising JIT in all circumstances. It should be possible to compile the class libraries with or without logging. Yes - that was my thought which I was hoping someone would bring up and I wouldn't have to :) geir - 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] internationalization
Not sure if it's particularly relevant, but the piece on Eclipse performance bloopers is a good read: http://www.eclipse.org/eclipse/development/performance/bloopers.html Specifically, it mentions items to do with using string keys, the dangers of using substring() and why they created their own binding from messages-to-keys framework instead of using the standard Java property list. Alex. On 31/05/06, Tim Ellison [EMAIL PROTECTED] wrote: I meant that the mechanism we currently have in LUNI (i.e. a resource file of externalized strings and a helper class like Msg to load the string and format it etc.) can be duplicated in each module that has externalized strings e.g. for exception messages. Of course, each module would only have its own messages. - 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] logging from within our implementation
Alex Blewitt wrote: They removed the debugging statements, and it ran so fast that they discovered all kinds of race conditions that they hadn't designed for. So they had to put the debugging statements back in to slow it down before shipping it to the customer :-) Mind you, I expect that marketing would have jumped on the bandwaggon with 2.0! Much faster than 1.0! but I didn't hang around long enough there to find out :-) I ran into this same exact problem years ago working on one of the first multi-processor direct-to-disk digital audio recording/editing systems. We inherited the halfway done OS from someone and our job was to finish it. It worked ok but had a lot of yammering to the console, so we knocked out all the debug printfs. It stopped working. (There is no close enough when feeding audio to a D/A... if you are late, you are late and you can hear it...) There were two of us doing it as a consulting project, and I can to this day remember the look of utter fear in my partner's eyes as we had about 3 weeks left to the biggest tradeshow of the year. We eventually got it working, but it was a very valuable and painful lesson. geir - 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] millions of rmi tests
Mikhail Loenko wrote: 2006/5/31, Geir Magnusson Jr [EMAIL PROTECTED]: Are there really 5000+ tests against *one* CTOR? [SNIP] I did not review all the 5000+ tests manually. I'm actually very happy to hear that. geir - 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] millions of rmi tests
Alexei Zakharov skrev den 31-05-2006 11:50: Hi, Just like to pay your attention on JUnit best practices concerning this topic (in case if you are talking about UNIT tests): http://junit.sourceforge.net/doc/faq/faq.htm#best_2 Especially paragraphs two and three. If I understand this correctly this is about testing RMI where the whole point is that get/set are not too simple to break anymore :) Glad that care is taken to getting this absolutely right. -- Thorbjørn smime.p7s Description: S/MIME Cryptographic Signature
Re: [VOTE] Acceptance of HARMONY-438 : DRL Virtual Machine Contribution
+1 On 5/30/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I have received the ACQs and the BCC for Harmony-438, so I can assert that the critical provenance paperwork is in order and in SVN. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. I think that getting this into SVN and letting people supply patches against SVN will be productive... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn 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] HARMONY vs. J2SE API source, binary compatibility: JAPI for 1.5 required
Looking through the mail thread: [classlib] JAPI data to drive packages to completion and following the link I found that looks like JAPI somehow supports part of 1.5 features (at least generics). It would be interesting to know for sure which of 1.5 features JAPI supports and which not, to understand what JAPI lacks (or be sure it has everything) to test 1.5 source compatibility of HY vs. conformant APIs. Mark, could your please point me to the document (if know any) that describes what of 1.5 features JAPI supports or provide a link to the tool's binaries to try. Thanks for your help, Vladimir On 5/15/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: Thanks Leo for your input. It forces me to think about some aspects of compatibility again. On 5/6/06, Leo Simons [EMAIL PROTECTED] wrote: On Sat, May 06, 2006 at 12:33:52PM +0700, Vladimir Ivanov wrote: Recently I thought about guaranteeing binary and source compatibility between HARMONY API and other compatible J2SE API implementations, what is our goal and how to check it, automation. Let me share my thoughts - for us to understand clearly what we want and how to test it. Thanks, vladimir, very clear! === Some observations === Observation #1: I think, in general, binary compatibility is a weaker requirement then source compatibility and is completely covered by source compatibility. Hmm. For the general form of general, this is not true, which stems from the use of preprocessors and non-deterministic transformations with which the non-java world is full. Eg when you do C development and change the definition of how big an int is, you lose binary compatibility but preserve source compatibility if this definition is inherited. In the specific, you might very well be very right here, which is quite interesting...how'd you come to these observations? Can I read more about them elsewhere? This observation based on another observation that compiler does linking (name resolution) in the same way as runtime (seems, for your example with C language it will not break linking, i.e. binary compatibility in terms of JLS). Of cause, if the compiler does not start linker or rules for compilation and runtime are different it will not work, but I know only some primitive assemblers that violate these rules. Sorry, I can't refer to articles just because I don't know any one related to source compatibility 'in general'. My observation based on the experience only. Observation #2: I think, talking about 1.4, checking of 2-way binary compatibility + throws clause + inheritance hierarchy will guarantee 2-way source compatibility. I did not find any contra examples. + serialized form I can imagine naughty/hacky code that uses reflection would be able to violate that rule too. The AOP toolkits are a good example of pushing the limits, eg aspectwerkz @ codehaus.org. The JVMS defines for java runtime that linking includes verification, preparation and resolution. Conformat compiler generates valid code. The preparation phase is memory allocation + check for AbstractMethodError. The resolution phase include checks for IllegalAccessError, InstantiationError, NoSuchFieldError and NoSuchMethodError. But compiler does all these 5 checks so source compatibility include binary (for java). Correct serialized form is not required for source/ binary compatibility (it is not affect linking/ compilation), so harmony target may be extended to 2-way-source compatibility and 2-way-serialized form compatibility. As for reflection, seems, the linker does the same checks as compiler (elements are mirrored to the wrappers like java.lang.reflect.Method and both checks types of wrappers only). It will be very useful If your provide code example to think how it can be eliminated. === What is our (Harmony) goal? === In terms of these definitions, ideally, I suppose we want that Harmony is 2-way source compatible with the conformant J2SE API implementation (RI API) to make sure that any application compiled with RI API can be compiled with Harmony and vice versa yep, 2-way-source compatible and 2-way-binary compatible. Agree. 2-way-source compatible and 2-way-serialized form compatible === Questions === 2. What more checks should be added to JAPI to guarantee 2-way source compatibility for 1.5? You know, I can't even think of a good way to do implement the checks for the generics, let alone think of more! Seems, it can be done for case with generic because all needed information stored to the class file. For example, additional checks for source compatibility may be implemented to convert information from the class file 'Signature' attribute to the textual representation of method's signature (with parameters rename for generic names). If we all agree that our target is 2-way source compatible and 2-way-serialized form compatible it would be good to define the complete list of
Re: [VOTE] Acceptance of HARMONY-438 : DRL Virtual Machine Contribution
+1 Etienne Geir Magnusson Jr wrote: I have received the ACQs and the BCC for Harmony-438, so I can assert that the critical provenance paperwork is in order and in SVN. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. I think that getting this into SVN and letting people supply patches against SVN will be productive... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ signature.asc Description: OpenPGP digital signature
Re: [DRLVM] adding write barriers to Jitrino.JET
On 5/31/06, Weldon Washburn [EMAIL PROTECTED] wrote:
DRLVM contains a simple JIT called Jitrino.JET in addition to a highly
optimizing JIT. The simple JIT seems to be a better choice for
starting the write barrier work.
Looking at Jitrino.JET sources, it looks like the best place to add
write barriers is in cg_ia32.cpp: Compiler::gen_st() {...} Does
this seem right?
No, this method is used to store operand stack item to local variable. If
you're interested in writing to fields then Compiler::gen_field_op is the
right place. We can generate a call to VM or GC helper in this method. To
create a call to any VM helper (which may throw Exception or force GC) you
should use Compiler::gen_call_vm() method.
Also, I have looked for documentation on Jitrino.JET but have not been
able to locate it.
The brief overview of Jitrino.JET features is in DRL VM Developers Guide.
For more detailed information you can generate Doxygen documentation. To
generate Doxygen documentation for Jitrino.JET browse to vm/jitrino/src/jet
folder and run 'doxygen -g', 'doxygen Doxyfile' commands.
It would be nice see some graphic documentation on
how the compiler spill/fills between the stack and registers. And
also how the compiler deals with the live ranges of reference
variables.
Jitrino.JET is designed to be a pretty simple baseline compiler. It does
not perform optimizations or data/control flow analysis. Operands do not
live across call sites on registers. i.e. Jitrino.JET spills into memory
every operand before a call. The live range of operand is exactly the same
as in bytecode, so even if object reference will never be used again, but
occupies a local variable or stack slot in Java bytecode, Jitrino.JET will
report it to GC during enumeration.
In specific how root set enumeration works. While not
absolutely essential for hacking in write barriers, it will help a
bunch during the debug stage.
Root set enumeration works as follows: Jitrino.JET emulates Java
stack/locals and has reserved areas in stack frame (see
Jitrino::Jet::StackFrame class) to map bytecode locals and stack slots. For
every GC enumeration point JET maintains two masks: GC map for locals and
GC map for stack which define which variables and which stack slots must
be reported to GC. Both masks are saved to StackFrame in runtime right
before GCenumeration point, but calculated separately. Locals mask is always
calculated in
runtime: every store operation changes a bit in mask. Stack operands mask is
calculated during compilation and
is a constant for every GC enumeration point.
It seems not to be a problem to implement WB support in Jitrino.JET, let's
discuss requirements and design.
How will it affect VM or GC ? The WBs will also require support from both VM
and GC. Do you have ideas on VM/GC interface for this?
Also what will be usage and testing scenarios in the nearest future?
--
Mikhail Fursov
Intel Middleware Products Division
Re: [classlib] internationalization
Yep, we discussed that a while ago. IIRC there was some debate about how the message keys should look. Today we have short strings (e.g. K1234) and there was a proposal to make that module.id (e.g. beans.42). I recall some objections to that proposal but cannot recreate them right now. We didn't go on to discuss the Eclipse technique of using a Message type with fields for the messages. Regards, Tim Alex Blewitt wrote: Not sure if it's particularly relevant, but the piece on Eclipse performance bloopers is a good read: http://www.eclipse.org/eclipse/development/performance/bloopers.html Specifically, it mentions items to do with using string keys, the dangers of using substring() and why they created their own binding from messages-to-keys framework instead of using the standard Java property list. Alex. On 31/05/06, Tim Ellison [EMAIL PROTECTED] wrote: I meant that the mechanism we currently have in LUNI (i.e. a resource file of externalized strings and a helper class like Msg to load the string and format it etc.) can be duplicated in each module that has externalized strings e.g. for exception messages. Of course, each module would only have its own messages. - 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: [classlib] logging from within our implementation
On the 0x17A day of Apache Harmony Alex Blewitt wrote:
Moral 1: saying 'It's OK, debug logging can be turned off and
log.debug(msg) is inexpensive' is a lie. If you really feel the need
for sprinkling debug statements everywhere (and I'm with others in
using a good IDE to track down problems) then surround every debug
with if (log.debugEnabled()) { log.debug(msg) }. Yes, it has the same
effect, but at least you don't bother wasting the calcuation of the
message itself, and in this case, even a dozy JIT can optimise it
away.
+1 for log.debugEnabled() :)
to optimize away log.debug(obj) JIT should perform devirtualization for
toString(), with escape analysis. That may turn out to be too
expensive. So, a reasonable JIT may optimize it some day, but not
always :)
BTW, highly optimizing JIT from the DRLVM contribution (=Jitrino.OPT)
does *not* perform escape analysis yet. That resides in TODO list :)
In fact, all-pure-java annotations may help to completely solve the
issue. There may be hints for JIT that it is safe to optimize some
code in a certain way. In release mode some pieces of code can be
annotated for deletion. Is it a good practice to support annotations
of that kind in Harmony JITs? Or is it a dirty hack? :)
--
Egor Pasko, Intel Managed Runtime 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: [DRLVM] adding write barriers to Jitrino.JET
2006/5/31, Mikhail Fursov [EMAIL PROTECTED]: No, this method is used to store operand stack item to local variable. If you're interested in writing to fields then Compiler::gen_field_op is the right place. We can generate a call to VM or GC helper in this method. To create a call to any VM helper (which may throw Exception or force GC) you should use Compiler::gen_call_vm() method. FYI: Write barrier GC implementation doesn't throw exceptions or starts garbage collection. The whole idea of write barriers is to make them as lightweight as possible. It seems not to be a problem to implement WB support in Jitrino.JET, let's discuss requirements and design. How will it affect VM or GC ? The WBs will also require support from both VM and GC. Do you have ideas on VM/GC interface for this? Also what will be usage and testing scenarios in the nearest future? The VMGC interfaces is already exists in DRLVM. The only interface is missing: JIT-VM helper. -- Ivan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Acceptance of HARMONY-438 : DRL Virtual Machine Contribution
+1 Geir Magnusson Jr wrote: I have received the ACQs and the BCC for Harmony-438, so I can assert that the critical provenance paperwork is in order and in SVN. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. I think that getting this into SVN and letting people supply patches against SVN will be productive... geir - 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
Etienne, Some words about your example. OPEN doesn't rely on any particular object layout, but tries to define functional interface for object access purposes. Open_Managed_Object_Handle is used to access this functionality from the components other than VM Core. In order to eliminate performance degradation in such overhead, OPEN defines: - Functions that JIT-compiled code calls during its execution (So called Helpers in OPEN) for quick access to objects from the managed code, - Java methods that interact with the managed code of Java class libraries (ObjectAccessors) for quick access from Java API They could be even inlined in managed code thus eliminating any modularization influence. So, any reasonable object layout could be used in OPEN compatible VM implementation, including bidirectional one. Thanks, Andrey On 5/29/06, Etienne Gagnon [EMAIL PROTECTED] wrote: Hi Anton, Are you proposing that all Harmony JVMs must abide by the OPEN proposal? If yes, I think that some process has to be put in place to present and discuss each of this proposal's part, and dedicate time to do so. IMO, I don't think that everyone (in the JVM sub-communityof Harmony) can simply read through this proposal and be able to make an enlightened decision about it. I think that each point would gain much from being presented along the motivation behind it. For example, would your OPEN proposal work with a bidirectional object layout, without incurring prohivitive performance costs? [Just asking, I didn't have time to read through all of it...] Of course, this is only an opinion. :-) Etienne - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Acceptance of HARMONY-438 : DRL Virtual Machine Contribution
+1 -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 30, 2006 9:06 PM To: harmony-dev@incubator.apache.org Subject: [VOTE] Acceptance of HARMONY-438 : DRL Virtual Machine Contribution I have received the ACQs and the BCC for Harmony-438, so I can assert that the critical provenance paperwork is in order and in SVN. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. I think that getting this into SVN and letting people supply patches against SVN will be productive... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] deploy directory reorganised into HDK shape
Does this have any affect on the Eclipse Plug-in for Harmony VM type? Do we just point at 'deploy/jdk' instead of 'deploy' now? -Nathan -Original Message- From: Oliver Deakin [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 31, 2006 3:48 AM To: harmony-dev@incubator.apache.org Subject: [classlib] deploy directory reorganised into HDK shape Hi all, Tim has just applied the patch for HARMONY-469. This patch changes the build scripts so that the deploy directory is laid out in the same way as the hdkbase directory described in [1]. So from SVN revision r410479, when you build the classlib it will create a directory structure that looks like: deploy \---jdk |---jre \---include For those who are already developing in classlib using the IBM VME, you will need to move your VME directory from deploy/jre/bin/default to deploy/jdk/jre/bin/default. After that the old deploy/jre directory can be deleted. You should then be able to run tests and continue developing as usual. Anyone who is newly coming into the project who wants to use the IBM VME should grab the latest versions (Harmony-vme-win.IA32-v3.zip and Harmony-vme-linux.IA32-v3.tar.gz) at: https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_USsourc e=ahdk These VME packages are organised with the following layout: EXTRACT_DIR | +---jre || |\---bin | | | \---default | \---vme_license so that they can be unpacked directly into the classlib deploy directory structure (under deploy/jdk) Instructions on developing and building the Harmony classlib can be found at [2]. Regards, Oliver [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/hdk.html [2] http://incubator.apache.org/harmony/subcomponents/classlibrary/build_class lib.html -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] deploy directory reorganised into HDK shape
Hi Nathan, Good catch - you will need to point your Installed JREs dialog at the deploy/jdk/jre directory instead of deploy/jre. No changes to the plug-in itself should be needed however. Thanks for spotting that! Regards, Oliver Nathan Beyer wrote: Does this have any affect on the Eclipse Plug-in for Harmony VM type? Do we just point at 'deploy/jdk' instead of 'deploy' now? -Nathan -Original Message- From: Oliver Deakin [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 31, 2006 3:48 AM To: harmony-dev@incubator.apache.org Subject: [classlib] deploy directory reorganised into HDK shape Hi all, Tim has just applied the patch for HARMONY-469. This patch changes the build scripts so that the deploy directory is laid out in the same way as the hdkbase directory described in [1]. So from SVN revision r410479, when you build the classlib it will create a directory structure that looks like: deploy \---jdk |---jre \---include For those who are already developing in classlib using the IBM VME, you will need to move your VME directory from deploy/jre/bin/default to deploy/jdk/jre/bin/default. After that the old deploy/jre directory can be deleted. You should then be able to run tests and continue developing as usual. Anyone who is newly coming into the project who wants to use the IBM VME should grab the latest versions (Harmony-vme-win.IA32-v3.zip and Harmony-vme-linux.IA32-v3.tar.gz) at: https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_USsourc e=ahdk These VME packages are organised with the following layout: EXTRACT_DIR | +---jre || |\---bin | | | \---default | \---vme_license so that they can be unpacked directly into the classlib deploy directory structure (under deploy/jdk) Instructions on developing and building the Harmony classlib can be found at [2]. Regards, Oliver [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/hdk.html [2] http://incubator.apache.org/harmony/subcomponents/classlibrary/build_class lib.html -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - 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] adding write barriers to Jitrino.JET
On 5/31/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: 2006/5/31, Mikhail Fursov [EMAIL PROTECTED]: No, this method is used to store operand stack item to local variable. If you're interested in writing to fields then Compiler::gen_field_op is the right place. We can generate a call to VM or GC helper in this method. To create a call to any VM helper (which may throw Exception or force GC) you should use Compiler::gen_call_vm() method. FYI: Write barrier GC implementation doesn't throw exceptions or starts garbage collection. The whole idea of write barriers is to make them as lightweight as possible. gen_call_vm() is more heavyweight( as Ivan explains above ), but that's why the higher level goals of this feature development would be good to know. Prototyping in .Jet cannot really have a performance focus. Weldon, would it be right to call this a proof of concept, to be later redone in the .OPT jit when necessary? It seems not to be a problem to implement WB support in Jitrino.JET, let's discuss requirements and design. How will it affect VM or GC ? The WBs will also require support from both VM and GC. Do you have ideas on VM/GC interface for this? Also what will be usage and testing scenarios in the nearest future? The VMGC interfaces is already exists in DRLVM. The only interface is missing: JIT-VM helper. Not sure that I understood what you said here...are you saying that the VM_GC interface has (stubbed out) barriers related entries( eg., gc_requires_barrier()/gc_write_barrier()), but the JIT-VM Helper runtime support interface does not have the necessary barrier helper entries in this code version? It may be worth considering if we want JET to just call the barrier functionality( with from/to/and slot locations )and the barrier helper actually do everything ... including generating the store. May be unconventional, but more modular. Thanks, Rana -- Ivan - 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] logging from within our implementation
Hi all,
How about using Velocity as Preprocessor.
You could put all logging Statements between an
//#if ($debug)
and
//#end
So the Code would stay pure java, and the debug Version could be compiled
without a Preprocessor.
Regards,
Soeren
Anton Luht schrieb:
It is possible to remove all calls to logging below a certain level
from .class files using BCEL:
http://surguy.net/articles/removing-log-messages.xml . In this example
logging is removed on fly when class is loaded, but this tool can be
run against class files in the process of building release version.
For example, debug version can contain all logging and release - only
errors. This approach has one disadvantage: it is non-standard and
looks like a dirty hack :)
On 31 May 2006 19:24:18 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x17A day of Apache Harmony Alex Blewitt wrote:
Moral 1: saying 'It's OK, debug logging can be turned off and
log.debug(msg) is inexpensive' is a lie. If you really feel the need
for sprinkling debug statements everywhere (and I'm with others in
using a good IDE to track down problems) then surround every debug
with if (log.debugEnabled()) { log.debug(msg) }. Yes, it has the same
effect, but at least you don't bother wasting the calcuation of the
message itself, and in this case, even a dozy JIT can optimise it
away.
+1 for log.debugEnabled() :)
-
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] logging from within our implementation
On 5/30/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Wednesday 31 May 2006 00:46 Ivan Volosyuk wrote:
Any good behaving optimizing runtime would inline empty methods into
nothing and therefore no performance impact would be made.
Excelent! This is much better and simplier.
public final class CLogger {
public static void msg(Object... ) {..}
}
Hmm, I see one drawback of this approach: arguments will still be
evaluated even if logger itself will be empty. So, some care needed to
maintain performance with such logger.
If dead code elimination is done after inlining, then most likely code
like
string concatination and stuff like that would be deleted as well.
1 IMO ceki's next generation bridging API has the signatures much closer to
being right than any other lightweight API i know of. one idea is that you
provide methods with extra parameters that are concatinated in the method
(if needed). for example:
debug(Object message)
debug(Object message, Object parameterOne)
debug(Object message, Object parameterOne, Object parameterTwo)
debug(Object message, Object parameterOne, Object parameterTwo, Object
parameterThree)
for a project such as harmony, it seems reasonable (to me) to restrict the
allowed logging calls to a limited number of parameters. developers should
remove any unreasonable calls before checking. so this solution might be a
good match.
2 for harmony, i'd consider not using a logging class at all. add private do
nothing template methods to any class that is likely to need logging. if a
developer needs to turn on logging for a class they run an enhancer to wire
those calls to an appropriate logging architecture.
for example:
public class DoSomethingCool {
public void whatever(What what, Ever ever) {
debug(This is really complex!, what, ever);
...
}
private debug(Object message) {}
private debug(Object message, Object parameterOne) {}
private debug(Object message, Object parameterOne, Object parameterTwo)
{}
private debug(Object message, Object parameterOne, Object parameterTwo,
Object parameterThree) {}
}
- robert
Re: [DRLVM] adding write barriers to Jitrino.JET
On 5/31/06, Rana Dasgupta [EMAIL PROTECTED] wrote: On 5/31/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: 2006/5/31, Mikhail Fursov [EMAIL PROTECTED]: No, this method is used to store operand stack item to local variable. If you're interested in writing to fields then Compiler::gen_field_op is the right place. We can generate a call to VM or GC helper in this method. To create a call to any VM helper (which may throw Exception or force GC) you should use Compiler::gen_call_vm() method. FYI: Write barrier GC implementation doesn't throw exceptions or starts garbage collection. The whole idea of write barriers is to make them as lightweight as possible. I don't care about how lightweight the write barrier at this stage of development. See below. gen_call_vm() is more heavyweight( as Ivan explains above ), but that's why the higher level goals of this feature development would be good to know. Prototyping in .Jet cannot really have a performance focus. Correct. Performance is a non-goal for the initial bring up on .JET. My thinking is that once .JET/MMTK is bullet proof, we worry about bringing up the optimizing JIT. Meanwhile the bullet proof .JET is not modified so that we can use it to chase write barrier bugs in the optimizing compiler. Once the optimizing compiler is stable and the lightweight WB's are inlined, the third stage is to go back and performance profile .JET. Use this perf info as a guide to fix .JET write barrier performance problems. Weldon, would it be right to call this a proof of concept, to be later redone in the .OPT jit when necessary? Instead of proof of concept, I would use the term, initial bring up. It seems not to be a problem to implement WB support in Jitrino.JET, let's discuss requirements and design. How will it affect VM or GC ? The WBs will also require support from both VM and GC. Do you have ideas on VM/GC interface for this? I am reading the MMTK source code now. I should have comments on mix/matching MMTK interface and OPEN and DRLVM GC interface(s) soon. Also what will be usage and testing scenarios in the nearest future? Probably the best option is to test write barriers using MMTK. The existing GC in DRLVM (gcv4) is probably going to be too hard to work with. Also, writing a GC from scratch is a possibility but I would rather go with an existing, known to work GC (mmtk or some other battle tested 3rd party open source GC). The VMGC interfaces is already exists in DRLVM. The only interface is missing: JIT-VM helper. Yes. I am aware of this interface. I need to look at harmony-438 sources to see if it has changed since I last worked on this interface back when I posted ORP to sourceforge in 2000. If memory serves me correct, ORP contains GCV3 which is an incremental moving collector. And write barriers were working just fine. Not sure that I understood what you said here...are you saying that the VM_GC interface has (stubbed out) barriers related entries( eg., gc_requires_barrier()/gc_write_barrier()), but the JIT-VM Helper runtime support interface does not have the necessary barrier helper entries in this code version? I don't want to inline write barrier code in Jitrino.JET during this startup stage. It needs to call a runtime helper function. If the function is missing, it needs to be added to the runtime helper table. It may be worth considering if we want JET to just call the barrier functionality( with from/to/and slot locations )and the barrier helper actually do everything ... including generating the store. May be unconventional, but more modular. I really want to take the lazy way out. If it is easier to leave the store code as it is, then that's what will be done. If it is easier to clump the WB code and the java store code together, then do that instead. Thanks, Rana -- Ivan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn 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: [DRLVM] adding write barriers to Jitrino.JET
2006/6/1, Rana Dasgupta [EMAIL PROTECTED]: How will it affect VM or GC ? The WBs will also require support from both VM and GC. Do you have ideas on VM/GC interface for this? Also what will be usage and testing scenarios in the nearest future? The VMGC interfaces is already exists in DRLVM. The only interface is missing: JIT-VM helper. Not sure that I understood what you said here...are you saying that the VM_GC interface has (stubbed out) barriers related entries( eg., gc_requires_barrier()/gc_write_barrier()), but the JIT-VM Helper runtime support interface does not have the necessary barrier helper entries in this code version? Yes, exactly. It may be worth considering if we want JET to just call the barrier functionality( with from/to/and slot locations )and the barrier helper actually do everything ... including generating the store. May be unconventional, but more modular. Actually, this is the best way to do that. Thus we allow much flexibility for the implementation of write barriers. I have found a few exceptions from this rule in DRLVM VM code. It is the implementation of atomic exchange of object field value, arraycopy and object_clone. We should think about this to. Let me give you a few details. We have in DRLVM implementation the atomic exchange of value stored in object field. It is required IMO for the j.u.atomics package. It require some additonal function in GC interface to do atomic swap of the value with write barrier. Object clone and System.arraycopy write/modify whole object with number of references in it. For the performance its currently use special write barrier function which simply gives the object reference saying: the whole object is changed - do something. We can leave the variant of write barrier or just remove it and change these functions respectivly. Best regards, -- 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: JSSE provider contribution
Tim Ellison wrote: great, thanks Boris. +1! that's awesome! Tim Boris Kuznetsov wrote: Dear all, I would like to announce one more contribution to Harmony on behalf of Intel. The archive with the contribution is uploaded to the following location: http://issues.apache.org/jira/browse/HARMONY-536 This contribution contains the implementation of the JSSE service provider for x-net component. The Java* Secure Socket Extension (JSSE) service provider enables secure Internet communications. The code is a result of efforts of Intel Middleware Product Division team. All code is pure Java. The implementation is done according to Java 1.5, TLS v1.0 and SSL v3 protocol specifications. The implementation uses available crypto algorithms provided by some crypto provider (e.g. BC provider). The archive contains the README file that explains the things doable with this code. But, should any additional clarifications be required, I'll be happy to provide them. You are welcome to try it out! Thank you, Boris Kuznetsov 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] -- Stefano. - 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] generics puzzler (was: Re: Thanks Stepan! (was: Re: [jira] Resolved: (HARMONY-454) [classlib][luni] java.util.Set generics uplift and related changes))
For anyone interested, I finally figured out the answer to this puzzle.
The following code compiles without error or warning using the new foreach
loop.
for (Map.Entry? extends K, ? extends V entry : map.entrySet()) {
entry.toString();
}
The way to make this work without a compile error or warning and use an
Iterator, you have to declare the Iterator just right.
Iterator? extends Map.Entry? extends K, ? extends V it =
t.entrySet().iterator();
while(it.hasNext()) {
Map.Entry? extends K, ? extends V entry = it.next();
}
The key is the ? extends before the Map.Entry declaration.
-Nathan
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 11, 2006 3:30 AM
To: harmony-dev@incubator.apache.org
Subject: [classlib] generics puzzler (was: Re: Thanks Stepan! (was: Re:
[jira] Resolved: (HARMONY-454) [classlib][luni] java.util.Set generics
uplift and related changes))
But the question remains in my mind whether there is any generic type
definition you could write that would allow you to cast the entrySet()
to a SetMap.Entrycapture-of ? extends K, capture-of ? extends V
equivalent?
To put it another way, I would expect that
for (Map.Entry? extends K, ? extends V entry : map.entrySet())
should complain that the declaration of 'entry' is not compatible with
the 'capture-of ? extends K' etc.
(It's still a useful cheat though)
Regards,
Tim
Neil Bartlett wrote:
Nathan,
It's a tricky one to be sure.
The problem is that the entrySet() method is returning a
SetMap.Entrycapture-of ? extends K, capture-of ? extends V,
which is incompatible with the type SetMap.Entry? extends K, ?
extends V. It's easier to describe why if I drop the extends K
and extends V part. So we have SetMap.Entry?, ? and
SetMap.Entrycapture-of ?, capture-of ?.
The first one, SetMap.Entry?, ? is a set of Map.Entries of
different types - ie it is a heterogeneous collection. It could
contain a Map.EntryLong, Date and a Map.EntryString, ResultSet
and any other pair of types, all in the same set.
On the other hand, SetMap.Entrycapture-of ?, capture-of ? is a
homogenous collection of the same (albeit unknown) pair of types. Eg
it might be a SetMap.EntryLong, Date, so all of the entries in the
set MUST be Map.EntryLong, Date.
In general, even if you could assign this to a local variable without
unchecked type safety warnings, you wouldn't be able to call any
methods on it because the compiler cannot check whether the access is
type-safe. For example you would not be able to call add() because the
Set must contain a specific type, but the compiler doesn't know which
specific type that is!
Regards
Neil
On 5/11/06, Nathan Beyer [EMAIL PROTECTED] wrote:
Does someone understand why this works this way? This seems so odd. I
know
there are quirks to the generics syntax, but this in an edge I haven't
run
into yet. I haven't been able to make this one click in my head yet.
This compiles fine:
public synchronized void putAll(Map? extends K,? extends V
map) {
for (Map.Entry? extends K,? extends V entry : map.entrySet())
{
...
}
}
This won't compile at all:
public synchronized void putAll(Map? extends K,? extends V
map) {
SetMap.Entry? extends K, ? extends V entries =
map.entrySet();
...
}
The error is: Type mismatch: cannot convert from
SetMap.Entrycapture-of ?
extends K,capture-of ? extends V to SetMap.Entry? extends K,?
extends
V
The suggested quick fix in Eclipse is Set? entries =
This reports a warning:
public synchronized void putAll(Map? extends K,? extends V
map) {
MapK,V map2 = (MapK,V)map;
}
The warning is: Type safety: The cast from Mapcapture-of ? extends
K,capture-of ? extends V to MapK,V is actually checking against the
erased type Map
The suggested quick fix in Eclipse is to the annotation:
@SuppressWarnings(unchecked).
-Nathan
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 10, 2006 6:59 AM
To: harmony-dev@incubator.apache.org
Subject: Thanks Stepan! (was: Re: [jira] Resolved: (HARMONY-454)
[classlib][luni] java.util.Set generics uplift and related changes)
Stepan Mishura (JIRA) wrote:
snip
2) To avoid casting while-loop was replaced with for-loop. Could
you
review the change?
I was scratching my head about this cast, so I was very pleased to
see
your elegant solution.
I must admit that I don't really understand why the for-loop version
is
inherently different (other than it 'hides' the casting) -- but I've
learned a new pattern there :-)
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
RE: [VOTE] Acceptance of HARMONY-438 : DRL Virtual Machine Contribution
+1 [Original Message] From: Geir Magnusson Jr [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Date: 5/30/06 10:10:22 PM Subject: [VOTE] Acceptance of HARMONY-438 : DRL Virtual Machine Contribution I have received the ACQs and the BCC for Harmony-438, so I can assert that the critical provenance paperwork is in order and in SVN. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. I think that getting this into SVN and letting people supply patches against SVN will be productive... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Acceptance of HARMONY-438 : DRL Virtual Machine Contribution
+1 -Stepan. On 5/31/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I have received the ACQs and the BCC for Harmony-438, so I can assert that the critical provenance paperwork is in order and in SVN. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. I think that getting this into SVN and letting people supply patches against SVN will be productive... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
[jchevm] Re: jchevm status?
That's great news...
And given the increase of activity around jchevm, can we remember to
prefix the subject line with [jchevm]... (I don't recall who started
this thread... doesn't matter... just a reminder)
Ivan Volosyuk wrote:
Archie, I have made some progress with classlib adapter. Now eclipse
starts and opens main window, just as with gnuclasspath. It works even
faster then it. Of cause, a lot of functionality is still missing. Now
I found a jchevm issue which prevents eclipse from working both on gnu
classpath and using this adapter. Here is the eclipse code:
private static void checkAccess() throws IllegalStateException {
StackTraceElement[] elements= new Throwable().getStackTrace();
if (!(elements[2].getClassName().equals(EditorsUI.class.getName())
||
elements[3].getClassName().equals(EditorsUI.class.getName(
throw new IllegalStateException();
}
This code checks access control in eclipse. The caller of the method
should be member function of class EditorsUI. As jchevm also reports
exception creation stack frames the access check doesn't work. I can
make a workaround in classlibadapter, but I think it should be better
fixed in the vm code, as the fix will work with gnu classpath too. If
you are too busy, I can make this fix for jchevm.
Best regards,
--
Ivan
2006/5/30, Archie Cobbs [EMAIL PROTECTED]:
Weldon Washburn wrote:
I tried to build Ivan's mods. I get a bunch of javac compiler errors
starting with, java.lang.reflect.Constructor is not abstract and does
not override abstract method isSynthetic()...
Unfortunately, I have zero time to spend on this project right now. I
looked at Ivan's mods. They seem reasonable and valuable. Please use
your best judgement on applying the patches to the code.
I don't want to slow down forward progress on the gnuclasspathadapter
project. It would be great if someone jumps in and take this project
forward.
Thanks.. I'm too busy to do much too unfortunately but I'll take
a look as soon as time permits.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
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] logging from within our implementation
Anton Luht wrote:
It is possible to remove all calls to logging below a certain level
from .class files using BCEL:
http://surguy.net/articles/removing-log-messages.xml . In this example
logging is removed on fly when class is loaded, but this tool can be
run against class files in the process of building release version.
For example, debug version can contain all logging and release - only
errors. This approach has one disadvantage: it is non-standard and
looks like a dirty hack :)
Yah. I'd rather see us add the logging this way rather than removing
it, using annotations or aspects or something... I'll try to experiment
with this tomorrow.
I really hate discussing logging. It's impossible to have a short
conversation where everyone agrees. Yoko, the CORBA project in the
incubator, is going through a very similar issue...
geir
On 31 May 2006 19:24:18 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x17A day of Apache Harmony Alex Blewitt wrote:
Moral 1: saying 'It's OK, debug logging can be turned off and
log.debug(msg) is inexpensive' is a lie. If you really feel the need
for sprinkling debug statements everywhere (and I'm with others in
using a good IDE to track down problems) then surround every debug
with if (log.debugEnabled()) { log.debug(msg) }. Yes, it has the same
effect, but at least you don't bother wasting the calcuation of the
message itself, and in this case, even a dozy JIT can optimise it
away.
+1 for log.debugEnabled() :)
-
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] adding write barriers to Jitrino.JET
On 5/31/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: 2006/6/1, Rana Dasgupta [EMAIL PROTECTED]: It may be worth considering if we want JET to just call the barrier functionality( with from/to/and slot locations )and the barrier helper actually do everything ... including generating the store. May be unconventional, but more modular. Actually, this is the best way to do that. Thus we allow much flexibility for the implementation of write barriers. I have found a few exceptions from this rule in DRLVM VM code. It is the implementation of atomic exchange of object field value, arraycopy and object_clone. We should think about this to. hmm I suspect the fundamental problem is that from the GC's perspective if a write to a heap location that contains a reference has occurred, the GC must also see the write barrier. Interestingly it is OK if the GC sees a write barrier without the corresponding field changing value. In this case, the GC will scan a field that simply has not changed. A small waste of time but still correct. From what I recall, there are two ways to solve the atomic (write_object, write_barrier) tuple problem. Either use an instruction like a DCAS (double compare and swap) or guarantee that a GC can not happen between the move to object field and write barrier code. The last time I looked, ia32 does not have DCAS instruction. In addition, each write of a reference to the Java heap would mean the HW issues an atomic operation. This could get expensive. Thus its not worthwhile discussing this approach further. An approach that I used in ORP was to guarantee that a thread can not be suspended for a GC between the write_object and write_barrier pair. The details are longer than this email will allow. Let me give you a few details. We have in DRLVM implementation the atomic exchange of value stored in object field. It is required IMO for the j.u.atomics package. It require some additonal function in GC interface to do atomic swap of the value with write barrier. I don't get it. Do you really mean to use atomic swap in the write barrier? Why? Where in harmony drlvm do I find this code? Object clone and System.arraycopy write/modify whole object with number of references in it. For the performance its currently use special write barrier function which simply gives the object reference saying: the whole object is changed - do something. We can leave the variant of write barrier or just remove it and change these functions respectivly. This is really confusing. I am looking at optimize_ia32.cpp:gen_native_arraycopy_fastpath() and object_generic.cpp:object_clone() from JIRA Harmony-438. Can you tell me which lines of code contain the special write barrier? As far as I understand, I should use Harmony-438 as the base to add the write barrier code. Is this correct? Best regards, -- 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] -- Weldon Washburn 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: jchevm status?
Archie Cobbs wrote: Ivan Volosyuk wrote: This code checks access control in eclipse. The caller of the method should be member function of class EditorsUI. As jchevm also reports exception creation stack frames the access check doesn't work. I can make a workaround in classlibadapter, but I think it should be better fixed in the vm code, as the fix will work with gnu classpath too. If you are too busy, I can make this fix for jchevm. Thanks for hunting this down. I'll work on a fix, which should be easy. Done (r410737). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
