to link succesfully.
Regards
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
_VERSION_SVN_TAG_
-#define VERSION_SVN_TAG 473506
+#define VERSION_SVN_TAG svn: This client is too old to work with
working copy '.'; please get a newer Subversion client
uh?
--
Stefano.
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
Intel Middleware ProductsDivision
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
, the version file will be fixed with a next
commit to VM.
It looks like we should really autogenerate it and remove it from svn as
was
suggested in another thread.
It is autogenerated. We just need to stop committing it...
geir
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
Or better call it ignore lists.
On 11/12/06, Pavel Pervov [EMAIL PROTECTED] wrote:
Geir,
Does SVN support some sort of exclude lists?
On 11/12/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Gregory Shimansky wrote:
On Saturday 11 November 2006 04:28 Stefano Mazzocchi wrote:
[EMAIL
but instead contain native resources cleanup code, which is required by any
choosen class unloading design to be implemented in DRLVM.
So, my +1 to commit this part, and hold on with the second, until
harmony-dev derives the decision.
Regards
--
Pavel Pervov,
Intel Enterprise Solutions Software
. It is because HARMONY-1558 has
changed
Sorry about that. I looked at Stefano's error messages. They are very
similar to the ones we battled a few days ago on linux 32-bit platform.
Pavel Pervov can probably tell you exactly what needs to be fixed.
I think I can figure out myself just looking
for me. I saw this yesterday. It is because HARMONY-1558 has
changed
Sorry about that. I looked at Stefano's error messages. They are very
similar to the ones we battled a few days ago on linux 32-bit platform.
Pavel Pervov can probably tell you exactly what needs to be fixed.
I think I can
allocation), it is proven to
work (patch available) and, also, is the most natural algorithm for DRLVM.
With the best regards,
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
on the
structure of DRLVM GCs, which is something I haven't explored.
DRLVM may work with (potentially) any number of GCs. Designing class
unloading the way, which would require markscan cooperation from GC, is not
generally a good idea (from my HPOV).
--
Pavel Pervov,
Intel Enterprise Solutions Software
-test.xml:58:
C:\_work_\harm
ony\enhanced\classlib\trunk\build\test_report not found.
Do I miss something important?
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
are the best people to decide on this.They are
literally the two people who know this code best :-)
Sure they are. That's why I've asked. They both have opposite POVs though.
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
between H1558 and H2000? In
any
case, I believe H1558 should be committed first. And H2000 will have to
pick up the pieces.
Everyone,
Comments? Suggestions?
--
Weldon Washburn
Intel Enterprise Solutions Software Division
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
if there are interdependencies between H1558 and H2000? In
any
case, I believe H1558 should be committed first. And H2000 will have to
pick up the pieces.
Everyone,
Comments? Suggestions?
--
Weldon Washburn
Intel Enterprise Solutions Software Division
--
Pavel Pervov,
Intel Enterprise Solutions
would vote for moving them to top level of
drlvm/trunk/vm directory to clearly indicate we have two JITs in DRLVM.
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
, and maybe it's
something someone can just do.
geir
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
allocated for this class loader. Look in HARMONY-2000 which brings
per-class loader pools to the extent.
SNIP
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
a reference pointer from object to its j.l.Class instance. MMTk
was
not designed with this idea in mind. It looks like you will need to fix
this part of MMTk and maintain it yourself. Steve did not seem thrilled
at
adding this support to MMTk code base.
SNIP
--
Pavel Pervov,
Intel Enterprise
move, it will be one more level of indirection for guarded
devirtualization: was object-vtable, will be object-vtable-class.
Unpinning vtables does not cause the need to enumerate them from JIT, if JIT
does not store pointers to them.
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
Fursov [EMAIL PROTECTED] wrote:
On 10/26/06, Pavel Pervov [EMAIL PROTECTED] wrote:
Unpinning vtables does not cause the need to enumerate them from JIT, if
JIT
does not store pointers to them.
AFAIU vtable is inlined into a special Java object.
If you move the object - vtable is also moved
and obj-class-vtable is bad for footprint) Is it
really the problem each JVM designer meets? :)
Some VM developers keep all info on the class in one block in Java heap:
java/lang/Class, VM part of class data, vtable of that class - everything.
:)
--
Pavel Pervov,
Intel Enterprise Solutions
Mikhail,
Now if you introduce one more level of indirection and start comparing
Classes, not VTables, you do not need to enumerate.
On 10/26/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/26/06, Pavel Pervov [EMAIL PROTECTED] wrote:
My statement is based on the following: JIT only needs
.
Please, do not hesitate to ask questions.
Best regards,
Aleksey Ignatenko,
Intel Enterprise Solutions Software Division.
--
Weldon Washburn
Intel Middleware Products Division
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
Enterprise Solutions Software Division.
--
Weldon Washburn
Intel Middleware Products Division
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
Maksim,
Am I right, that at the place you need to retrieve field from a class, you
have both field's name AND descriptor?
If so, you should move definion of FIeld*
class_lookup_field_recursive(Class*, const char*, const char*) from
vmcore/include/Class.h to include/jit_intf.h and change its
System.load() and
System.loadLibrary() differences. So the problem is solved and I have even
tested the code :)
--
Mikhail Fursov
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
a part of a component could be written in Java (e.g
.
EM, helpers), but not the whole component...
On 10/20/06, Pavel Pervov [EMAIL PROTECTED] wrote:
What about TM replacement (although it is almost impossible at the
moment)?
--
Mikhail Fursov
--
Pavel Pervov,
Intel Enterprise Solutions
+1 certainly.
Pavel Pervov,
Enterprise Solutions Software Division.
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
We're trying something a little different. I think Roy Fielding one
said something along the lines of when a community gets organized
enough to vote itself out
What about TM replacement (although it is almost impossible at the moment)?
Pavel.
On 10/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/20/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Yeap.
The following addresse both your issues.
class GCv5Magics {
static {
String
Mikhail,
You certainly can. Just add System.loadLibrary(component name) to the
static initialization block of a class, which declares that method and call
clinit for such class.
Example.
--
Component: gcv5.dll
Class, implementing fast path magics: GCv5Magics
Class source:
My alternative follows:
1) Each component which exports magics, provides JAR file with class
implementing these magics. Class name is described in (e.g.) Main-Class
attribute of JAR's manifest.
2) The class contains java fast path for helper, and a pair of native
methods: one for fast-slow path,
) A component (GC) must know its library name
2) java.library.path must be modified before the load and restored after
the load, because System.loadLibrary is not able to load library with
fully
qualified path.
Any other ideas?
On 10/20/06, Pavel Pervov [EMAIL PROTECTED] wrote:
Mikhail,
You
type.helpers_class. Then VM loads this class and
JIT uses this class' name to retrieve fast path helpers.
I, personally, prefer second choice here.
Anything else?..
Pavel.
On 10/20/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Pavel Pervov :
My alternative follows:
1) Each component which exports magics
The scenario I described earlier is impossible. Resolution of any class
referenced in some other class is performed by class loader, which loaded
that other class. So, no chance to load A and referencing class loader
(UCL) with this UCL.
Sorry for confusion.
Regards,
Pavel.
P.S. Still there
Mikhail,
EM, as I see it, is interchangeable component. Should we require defining
java.compiler for interpreted mode from all EMs?
My idea is to initialize java.compiler to some default value (none?) in
VM, and then overwrite it with actual value wherever actual information is
available (in EM
Geir,
please, look for thread titled [dlrvm] ClassCircularityError in recursive
compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is
really unstable) (and original thread [drlvm] smoke test : gc
PhantomReferenceQueueTest is really unstable). There were huge discussion
about
Altrenative idea would be to use just architecture name as the first
classification tag for architecture specific issues (including porting to
that arcitecture).
Examples can be: [ipf], [ia32], [em64t], etc.
Example of JIRA could be: [ipf][classlib][awt] natives build is broken
Regards,
Geir,
as I may observe, interpreter is broken both on windows and linux for at
least 3 days now. The interpreter library just does not load. From system
diagnostics it looks like SIGSEGV in initialization static block of the
library.
Regards,
Pavel.
On 10/15/06, Geir Magnusson Jr. [EMAIL
False alarm. It works just fine now.
But it was broken on Friday!.. Mistery.
Pavel.
On 10/15/06, Pavel Pervov [EMAIL PROTECTED] wrote:
Geir,
as I may observe, interpreter is broken both on windows and linux for at
least 3 days now. The interpreter library just does not load. From system
if we support it only with JET (in the
default mode JET compiles all methods first)? In this case if we see
ClassCircularityError in OPT we have a chance to return JIT_FAILURE to EM
and ask EM to compile this method with JET?
On 10/11/06, Pavel Pervov [EMAIL PROTECTED] wrote:
I suspect
On 10/12/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Wednesday 11 October 2006 16:15 Pavel Pervov wrote:
(Branching from original thread as this is different problem than in the
root message.)
Wasn't it the same problem, just happening on classlib initialization? I
think
the scenario
-pool allocations.
[1] http://issues.apache.org/jira/browse/HARMONY-1833
--
Alexey
12.10.06, Gregory Shimansky[EMAIL PROTECTED] написал(а):
On Wednesday 11 October 2006 16:15 Pavel Pervov wrote:
(Branching from original thread as this is different problem than in
the
root message.)
Wasn't
Yes, I am. :)
The common rule of not executing Java under native lock applies to JNI too.
Regards,
Pavel.
On 10/12/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
12.10.06, Pavel Pervov[EMAIL PROTECTED] написал(а):
Alexey,
The main issue here is why classloading (?) calls to GC under
On 10/12/06, Pavel Pervov [EMAIL PROTECTED] wrote:
Yes, I am. :)
The common rule of not executing Java under native lock applies to JNI
too.
Especially, if you hold VM internal lock.
Regards,
Pavel.
On 10/12/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
12.10.06, Pavel Pervov
no difference. Does it
matter if you go into recursion with a lazy resolution helper in runtime
of
with a recursive compilation?
On 10/12/06, Pavel Pervov [EMAIL PROTECTED] wrote:
Yes, I am. :)
The common rule of not executing Java under native lock applies to JNI
too.
Regards,
Pavel.
On 10
Michail,
Generally speaking I can think of fully user code which produces exactly the
same result.
So, workarounding this in one place (finalizers) just is not enough.
Regards,
Pavel.
On 10/11/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/11/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Geir,
sorry for confusion. The bug you are referring to is described in [1].
Regards,
Pavel.
[1]
*http://issues.apache.org/jira/browse/HARMONY-1814*http://issues.apache.org/jira/browse/HARMONY-1814
On 10/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I get this more often than not.
?
Would BEA or SUN VM be able to run the test?
I think we can create a separate discussion or JIRA for it.
On 10/11/06, Pavel Pervov [EMAIL PROTECTED] wrote:
Michail,
Generally speaking I can think of fully user code which produces exactly
the
same result.
So, workarounding this in one place
?
I remember I tried something similar but one of the RIs crashed :)
On 10/11/06, Pavel Pervov [EMAIL PROTECTED] wrote:
(Branching from original thread as this is different problem than in the
root message.)
Mikhail,
The following scenario will fail:
1) JIT compiles some method and resolves
Commenting on (1) I should note, that VM generally can't determine the fact
of initiating class loading; it can only be done in Java (except bootstrap
class loader, of course).
AFAIK, there is the bug: DRLVM does not record initiating class loader of a
class. (1) is just the consequence.
On
Geir, all,
I did reserched this failure some time ago. The same failure was observed on
gc.Finalizers.
Here is what I've found.
Now what is happening:
1) FinalizerThread is being run
2) java/lang/Object.notify()V is being compiled
3) java/lang/InternalError is being resolved
Dear all,
Can we exclude this task from DRLVM's build.xml default task? It takes most
of build time when rebuilding only several files while working with drlvm
code.
AFAIU, exect content of this directory exists at
platform_arch_compiler_config/deploy directory.
Regards,
Pavel Pervov.
Dear committers,
please, commit HARMONY-1594 to fix gcc 4.* build for Jitrino and jet
sources. Otherwise, it is a bit more complex to live on a linux with
compiler version 4.0 and above.
Regards,
Pavel Pervov.
Intel Middleware Products Division.
may need to revisit this issue in
sometime...
--
Regards,
Alexey
2006/9/25, Pavel Pervov [EMAIL PROTECTED]:
Ha! I discovered interesting article [1] about java launcher and class
loading.
Pavel.
[1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/findingclasses.html
On 9/25/06, Alexey
It is the revision from saturday, september, 23rd.
Regards,
Pavel.
On 9/25/06, Weldon Washburn [EMAIL PROTECTED] wrote:
Pavel,
I glanced at it. Was this patch made on an svn revision number from this
week?
On 9/23/06, Pavel Pervov [EMAIL PROTECTED] wrote:
Created Harmony-1558 [1
Chris,
As far as I understant, this is responsibility of a class loader to parse
Class-Path attribute of any jar file it has in its class path.
System class loader for DRLVM (which is URLClassLoader) does this.
Any objections?
Regards,
Pavel Pervov.
Intel Middleware Products Division.
On 9
;)
2006/9/25, Pavel Pervov [EMAIL PROTECTED]:
Chris,
As far as I understant, this is responsibility of a class loader to
parse
Class-Path attribute of any jar file it has in its class path.
System class loader for DRLVM (which is URLClassLoader) does this.
Any objections?
Regards,
Pavel
declares such responsibility?
This seems logical and now I recall why I let it to be forgotten ;)
2006/9/25, Pavel Pervov [EMAIL PROTECTED]:
Chris,
As far as I understant, this is responsibility of a class loader to
parse
Class-Path attribute of any jar file it has in its class path.
System class
Created Harmony-1558 [1] with the intention to attach all patches to it.
Step 1 patch attached - interested parties can review.
Regards,
Pavel.
[1] https://issues.apache.org/jira/browse/HARMONY-1558
On 7/24/06, Pavel Pervov [EMAIL PROTECTED] wrote:
Hello, all.
I would like to work
Geir,
Looks like you've missed adding file
enhanced/drlvm/trunk/vm/vmcore/include/jvmti_break_intf.h to SVN tree.
Regards,
Pavel.
On 9/23/06, Geir Magnusson Jr (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/HARMONY-1545?page=all ]
Geir Magnusson Jr closed
Tried it on Windows and found the problem which, as it looks like, have
never been caught before.
As I discovered, launcher uses platform specific line separators to parse
harmonyvm.properties on a specific platform. But haromynvm.properties, which
is copied into deploy, has unix line endings and
– constant pool and class
2) vtable.h – vtable
3) class_member.h – field and method entities descriptors,
exception handler descriptor
4) cci.h – code chunk entity (part of compiled method code)
2006/9/14, Alexey Varlamov [EMAIL PROTECTED]:
2006/9/13, Pavel Pervov [EMAIL
2006/9/13, Pavel Pervov [EMAIL PROTECTED]:
Not sure C++ friends are good design.
Umm, what is wrong with friends?
It's sort of breaking incapsulation ideology. Nothing more. :)
SNIP
For example, private members of Method _parse_exceptions()
_parse_local_vars(), _parse_line_numbers
For example, private members of Method _parse_exceptions()
_parse_local_vars(), _parse_line_numbers(), _parse_code() actually
should be public members of respective entities.
They should not. Nobody but Method knows nothing about local variable
tables
and line numbers stored in it. It
SNIP
The inclusion of external header files in GC is a continual battle. From
a
modularity standpoint, the external header files need to be excluded.
During GC debug its often useful to access class name, subclass name, etc.
What really needs to happen is class.h accessors need to be
,
Pavel.
On 9/13/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/9/11, Weldon Washburn [EMAIL PROTECTED]:
On 9/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/9/10, Pavel Pervov [EMAIL PROTECTED]:
Weldon,
one of good examples is static_method_block member variable of
struct
. Maybe the best thing
to do is post some patches so that we have examples to discuss.
Weldon
On 9/5/06, Pavel Pervov [EMAIL PROTECTED] wrote:
It's been long time this discussion stopped.
This may mean three things:
- first, everyone agrees this should be done and I'm ok to provide
, noone is really interested in making source code of DRLVM more
readable and more understandable, and I should drop this activity.
Meanwhile, I'd like to open jira and start posting patches there.
Regards,
Pavel.
On 7/25/06, Pavel Pervov [EMAIL PROTECTED] wrote:
Geir,
well
as I may observe, we strictly followed these rules up to now.
I wonder if it is posible to reproduce the scenario, described in the
forwarded mail, on Harmony running Eclipse...
Regards,
Pavel Pervov.
Intel Middleware Products Division.
On 8/4/06, Alex Blewitt [EMAIL PROTECTED] wrote
Michail,
you can get root class set to A and iterate all incarnations from there.
Regards,
Pavel.
On 7/24/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 7/24/06, Pavel Pervov [EMAIL PROTECTED] wrote:
Michail,
If some component external to VM core has direct access to class.h
development in separate functional groups to reduce
recompilation when working intensively with these files.
Hope, I answered, what you were asking about. :)
Regards,
Pavel.
On 7/24/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Pavel Pervov wrote:
On 7/24/06, Alexey Petrenko [EMAIL PROTECTED
, I'll do all these changes step-by-step with little patches coming
in.
Regards,
Pavel Pervov
Intel Middleware Products Division.
On 7/24/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
2006/7/24, Pavel Pervov [EMAIL PROTECTED]:
Hello, all.
I would like to work on cleaning the insides of Class.h header file.
This header is related to internal representation of java class inside
the
VM. Currently it contains all
thread to discuss these changes?
BTW we can do in in a thread with discussion of devirtualization
techniques.
?
On 7/24/06, Pavel Pervov [EMAIL PROTECTED] wrote:
On 7/24/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
2006/7/24, Pavel Pervov [EMAIL PROTECTED]:
Hello, all.
I would like
to member
variables of class and constant pool structures into interfaces thus
allowing to control their current usage.
Regards,
Pavel.
On 7/24/06, Weldon Washburn [EMAIL PROTECTED] wrote:
On 7/24/06, Pavel Pervov [EMAIL PROTECTED] wrote:
Hello, all.
I would like to work on cleaning
On 7/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
patch welcome ;)
geir
Working on it. :)
be dangerous.
WBR,
Pavel Pervov.
Intel Middleware Products Division.
of the page).
So, it's nice that VM won't crash if entered JNI function in exception
state, but it is obviously resposibility of native code (launcher in our
case) to check pending exceptions and process them as necessary _before_
calling into JNI.
Regards,
Pavel Pervov.
[1] http://java.sun.com
, it is reasonable that the user of JNI
functions (classlib launcher in our case) clears exception (or process it
otherwise) before calling to any JNI function.
With the best regards,
Pavel Pervov.
Intel Middleware Products Division.
source files on Windows.
Regards,
Pavel Pervov
Intel Middleware Products Division
I'd suggest switching the build to 1.5.
The rest will come shortly :)
Now that's a plan! :)
Yeah, indeed. :)
Seriously speaking, DRLVM is already allowed to load class files with
version 49. Certainly, some issues will be brought up while trying to run
DRLVM against class library compiled
class$
from the current version of java/lang/Character.
What is exact problem you are experiencing with this method? How did you get
to the fact it is related to java/lang/Character?
Pavel Pervov,
Intel Middleware Products Division.
82 matches
Mail list logo
