very similar.
geir
Gregory Shimansky wrote:
Evgueni Brevnov wrote:
You can look at the change here
http://issues.apache.org/jira/browse/HARMONY-2203
Could someone who knowns classlib native code internals better
than me
comment on this JIRA? I've added my comment from the general
Hmm no I cannot reproduce it. Did you build the VM? Does directory
build/win_ia32_msvc_debug/deploy/jre/include exist and does it contain
include files?
In jvmti.test.xml the include path is constructed like this
${build.deploy.dir}/include. So either it doesn't exist, or
build.deploy.dir
Elena Semukhina wrote:
On 11/16/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
Elena Semukhina wrote:
As Gregory mentioned ThreadTest.testJoinlongint() failure he observed
yesterday, I filed a http://issues.apache.org/jira/browse/HARMONY-2204
issue
for that. I saw this failure quite long
Elena Semukhina wrote:
On 11/17/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
Elena Semukhina wrote:
On 11/16/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
Elena Semukhina wrote:
As Gregory mentioned ThreadTest.testJoinlongint() failure he
observed
yesterday, I filed a
http
level breakpoints
support will have to be implemented.
On interpreter support is platform independent, so maybe I'll enable the test
for interpreter only when I understand what's wrong with failing assertion.
--
Gregory Shimansky, Intel Middleware Products Division
Egor Pasko wrote:
On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
-Xss is the lower stack limit, it doesn't specify the maximum
stack size, doesn't it?
What does lower stack limit mean? :) I think
Evgueni Brevnov wrote:
You can look at the change here
http://issues.apache.org/jira/browse/HARMONY-2203
Could someone who knowns classlib native code internals better than me
comment on this JIRA? I've added my comment from the general POV.
I would change the loop to detect only signal
Egor Pasko wrote:
On the 0x223 day of Apache Harmony Gregory Shimansky wrote:
Egor Pasko wrote:
On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
-Xss is the lower stack limit, it doesn't specify
Elena Semukhina wrote:
As Gregory mentioned ThreadTest.testJoinlongint() failure he observed
yesterday, I filed a http://issues.apache.org/jira/browse/HARMONY-2204
issue
for that. I saw this failure quite long ago but cannot reproduce it today
trying different platforms/EMs. When the test
} /
+--
/target
--
Gregory Shimansky, Intel Middleware Products Division
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
On Friday 17 November 2006 02:13 [EMAIL PROTECTED] wrote:
Author: geirm
+!--
+ * FIXME : the following awful little hack is because we noticed
that for whatever + * reason, we can't link with libjpg.a on at
least to kinds
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Pavel Afremov wrote:
On 11/13/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
So what is the point to have a test which would pass either way? Check
that it doesn't crash the VM, is it the only purpose for it?
I think yes. It should check
have older debug build at hand (svn = r474646) and
it also spills this stacktrace to system err but status is PASSED for
all execution engines.
Looks like smth hase changed in exceptions processing for interpreter.
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
Hello
Today a kernel tests which
Vladimir Ivanov wrote:
Hello everyone,
I started cruise control (stored in the buildtest module with patch from
issue 995) on the Windows XP and SUSE Linux boxes.
Both machines are identical (1 CPU - P4*3GHz, 1GB RAM, 120Gb HDD).
On each platform cruise control runs (as separate projects in СС
Alexey Varlamov wrote:
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
Alexey Varlamov wrote:
The guilty change is the following, which effectively turns on
VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
Well this is a patch from HARMONY-2018 which doesn't hide the fact that
it enables
Alexey Varlamov wrote:
2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
Alexey Varlamov wrote:
The guilty change is the following, which effectively turns on
VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
Well this is a patch from HARMONY
Alexei Zakharov wrote:
I prefer to name the updated patch some.patch_updated (if the name
of the original patch was some.patch). I am always puzzled when I
see two identical names in attachments.
You can always click on All tab to see not only comments, but status
and field changes, attached
the patch.
On 11/14/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/11/14, Gregory Shimansky [EMAIL PROTECTED]:
On Monday 13 November 2006 15:51 Elena Semukhina wrote:
On 10/26/06, Elena Semukhina [EMAIL PROTECTED] wrote:
After H-1823 has been committed, I still see intermittent failures
= oh_allocate_local_handle();
exc_cause-object = exception-exc_cause;
tmn_suspend_enable_recursive();
}
Cool. Could you please commit the fix?
OK, we definitely need a regression test for this.
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
Alexey Varlamov wrote:
2006/11/15
= oh_allocate_local_handle();
exc_cause-object = exception-exc_cause;
tmn_suspend_enable_recursive();
}
OK, we definitely need a regression test for this.
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
Alexey Varlamov wrote:
2006/11/15, Alexey
to finding
javac?
--
Gregory Shimansky, Intel Middleware Products Division
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Pavel Afremov wrote:
On 11/13/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
So what is the point to have a test which would pass either way?
Check
that it doesn't crash the VM
Geir Magnusson Jr. wrote:
Stefano Mazzocchi wrote:
Gregory Shimansky wrote:
Stefano Mazzocchi wrote:
I've tried to run the VM launcher and I get:
[EMAIL PROTECTED]
~/src/harmony/drlvm/build/lnx_em64t_gcc_debug/deploy/jre/bin $ ./java
Harmony Java launcher
Apache Harmony Launcher : (c
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
I still think that this is bogus
What if SOE machinery is broken?
We need to make this a predictable test.
Well I don't feel strongly to either side. We can use ulimit -s in
build.sh script which runs
Stefano Mazzocchi wrote:
Gregory Shimansky wrote:
On Tuesday 14 November 2006 00:51 Gregory Shimansky wrote:
I'm going to try to do this on my Gentoo at home now. It is mostly
bleeding edge up to date installation.
Now I see what you're talking about. The threading library of classlib doesn't
Gregory Shimansky wrote:
Stefano Mazzocchi wrote:
Gregory Shimansky wrote:
On Tuesday 14 November 2006 00:51 Gregory Shimansky wrote:
I'm going to try to do this on my Gentoo at home now. It is mostly
bleeding edge up to date installation.
Now I see what you're talking about. The threading
Pavel Afremov wrote:
On 11/13/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
So what is the point to have a test which would pass either way? Check
that it doesn't crash the VM, is it the only purpose for it?
I think yes. It should check that test doesn't crash VM if stack size isn't
enough
Stefano Mazzocchi wrote:
I'm happy to report that both classlib and drlvm at r474892 build on
x86_64/em64t
As Gregory suggested, I had to change the symlinks to from
/usr/lib/lib(jpeg|png).a to /usr/lib/lib(jpeg|png).so in order for the
link to avoid complaining.
Well Geir insists that we
Stefano Mazzocchi wrote:
Gregory Shimansky wrote:
Stefano Mazzocchi wrote:
I'm happy to report that both classlib and drlvm at r474892 build on
x86_64/em64t
As Gregory suggested, I had to change the symlinks to from
/usr/lib/lib(jpeg|png).a to /usr/lib/lib(jpeg|png).so in order for the
link
Stefano Mazzocchi wrote:
I've tried to run the VM launcher and I get:
[EMAIL PROTECTED]
~/src/harmony/drlvm/build/lnx_em64t_gcc_debug/deploy/jre/bin $ ./java
Harmony Java launcher
Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
Foundation or its licensors, as applicable.
On Wednesday 15 November 2006 02:11 Stefano Mazzocchi wrote:
Gregory Shimansky wrote:
Stefano Mazzocchi wrote:
I've tried to run the VM launcher and I get:
[EMAIL PROTECTED]
~/src/harmony/drlvm/build/lnx_em64t_gcc_debug/deploy/jre/bin $ ./java
Harmony Java launcher
Apache Harmony
)
at junit.textui.TestRunner.main(TestRunner.java:138)
TokenStreamException: antlr.TokenStreamException
E
Time: 71.596
There was 1 error:
1) test_3(java.lang.ClassGenericsTest4)java.lang.NullPointerException
--
Gregory Shimansky, Intel Middleware Products Division
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
One reason would be is that I don't know ant well enough to redesign
the whole stuff all together. I used the existing setup and init
targets which take care of including ancontrip and cctask jars.
If you ask me, I'd prefer make
Gregory Shimansky wrote:
On Saturday 11 November 2006 02:36 Pavel Pervov wrote:
Gregory,
Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I
believe it'll fix the build.
Thank you for a quick fix. The build works now. Don't try to run acceptance
tests though
Pavel Afremov wrote:
Hello
I think that Stack test should print pass if no stack overflow error is
happened.
Test should check processing of this error but not existing of it.
Optimizing compiler can do very deep recursion unrolling, and SOE can
happen
never in this case.
So what is
to pass again on all platforms and then we'll maintain no
regression state.
--
Gregory Shimansky, Intel Middleware Products Division
Stefano Mazzocchi wrote:
Gregory Shimansky wrote:
Gregory Shimansky wrote:
On Saturday 11 November 2006 02:36 Pavel Pervov wrote:
Gregory,
Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I
believe it'll fix the build.
Thank you for a quick fix. The build works now
Evgueni Brevnov wrote:
hmmm strange. The patch was tested on multi-processor system
running SUSE9. I will check if the patch misses something. Anyway, we
need to wait with the patch submission until we 100% sure how
hythread_monitor_init should behave.
Thanks
Evgueni
On 11/11/06, Gregory
On Tuesday 14 November 2006 00:51 Gregory Shimansky wrote:
I'm going to try to do this on my Gentoo at home now. It is mostly
bleeding edge up to date installation.
Now I see what you're talking about. The threading library of classlib doesn't
compile on x86_64. It fails with the same error
version, that is
gmake), even on win32 it exists in cygwin and mingw.
--
Gregory Shimansky, Intel Middleware Products Division
it from svn as was
suggested in another thread.
--
Gregory Shimansky, Intel Middleware Products Division
On 11/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Well, since the problem is repeatable :)
Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
Alexei Zakharov wrote:
Hi DRLVM fans,
I encountered a rather strange problem while working on some
class
Stefano Mazzocchi wrote:
Geir Magnusson Jr. wrote:
anyway, I can't build the native part of harmony/classlib
doing ant build-native results in
classlib/depends/libs/linux.x86_64
not being found.
There should be prebuilt ICU binaries. You can build them yourself or
you can take them from
Gregory Shimansky wrote:
Stefano Mazzocchi wrote:
Geir Magnusson Jr. wrote:
anyway, I can't build the native part of harmony/classlib
doing ant build-native results in
classlib/depends/libs/linux.x86_64
not being found.
There should be prebuilt ICU binaries. You can build them yourself
Stefano Mazzocchi wrote:
Gregory Shimansky wrote:
Stefano Mazzocchi wrote:
Geir Magnusson Jr. wrote:
anyway, I can't build the native part of harmony/classlib
doing ant build-native results in
classlib/depends/libs/linux.x86_64
not being found.
There should be prebuilt ICU binaries. You
’ is not a member of ‘Class’
[cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
:359: error: ‘struct Class’ has no member named ‘name’
Suggestions?
--
Gregory Shimansky, Intel Middleware Products Division
convenient if these conflicts go out.
Could we generate this file as part of the build process (it has only 4
strings)? May be some other solutions exists?
I'm not too familiar with VM build so I'll be glad if somebody takes care
about it :)
--
Gregory Shimansky, Intel Middleware
a pointer to
a data allocated somewhere not on the stack.
--
Gregory Shimansky, Intel Middleware Products Division
On Saturday 11 November 2006 01:43 Weldon Washburn wrote:
On 11/10/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
Same 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
, beer and
hair on my head. I said I am not an ant guru, didn't I?
--
Gregory Shimansky, Intel Middleware Products Division
, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Saturday 11 November 2006 01:43 Weldon Washburn wrote:
On 11/10/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
Same for me. I saw this yesterday. It is because HARMONY-1558 has
changed
Sorry about that. I looked at Stefano's error
think we need more investigation on whether or not the monitor has to be
locked in init.
--
Gregory Shimansky, Intel Middleware Products Division
Thanks for spotting this. I'll check on SUSE and if reverting this patch
helps, I'll revert it. I wonder why this doesn't break on more modern
linuxes.
Egor Pasko wrote:
Guys,
after commit of HARMONY-1907 (r472524) by Gregory ..
* Good news: builds OK :)
* Bad news: I am observing
Pavel Pervov wrote:
3.3.3 build crashes. I'm investigating the issue.
As a workaround measure, use 4.* to compile classlib and dlrvm.
Did you try 4.x on SUSE too? It looks more like dynamic libraries
loading problem because stack trace shows a resolution of native method
Weldon Washburn wrote:
1558 pass the pre-commit build test on my windows laptop. I have not
done
a post-commit clean svn checkout, build, build test. Mostly because
build
test makes my laptop unusable for over an hour. It would be good if
someone
can double verify the windows build is OK
Geir Magnusson Jr. wrote:
Alexei Zakharov wrote:
Hi DRLVM fans,
I encountered a rather strange problem while working on some class
library tests. At least two tests from the beans module hang (or
crash) while running on DRLVM debug builds but work fine on DRLVM
release builds. I thought that
and final output to something like deploy-x86_64? Also we could
separate debug/release built files in the same way.
--
Gregory Shimansky, Intel Middleware Products Division
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Hello
Today I tried to check what happens on x86_64 and I think I've found
some issues which need discussion
1. When classlib starts its built it tries to link 3 libraries and
headers to depends/libs/build/{jpeg,lcms,png} directories
53 seconds
BUILD FAILED
/home/hybld/continuum-working-directory/6/build.xml:114: exec returned: 1
Total time: 1 minute 58 seconds
***
*
...
--
Gregory Shimansky, Intel Middleware Products Division
objects
functionality? Is it a temporary limitation or inherent design restriction?
I don't think this limitation is serious, but if it exists it is probably
worth to mention it on the drlvm limitations wiki page.
--
Gregory Shimansky, Intel Middleware Products Division
---
Should be I have changed a hyperlink and sent patch to JIRA?
___
With Best Regards,
Irlyanov Dmitry
Intel Corporation
Middleware Products Division
--
Gregory Shimansky, Intel Middleware Products Division
this patch to be finally integrated into the code.
We should either agree to let it in or let it die. I support the first option.
Weldon, Geir, what do you think?
--
Gregory Shimansky, Intel Middleware Products Division
Gregory Shimansky wrote:
Salikh Zakirov wrote:
Gregory Shimansky wrote:
I think you could use 4.1.0 in Fedora Core 5. Since patch level
shouldn't really affect the C++ compilation restrictions, the same patch
should break on 4.1.0 as well.
Gregory, I've looked at harmony-1635.patch you've
Weldon Washburn wrote:
Folks,
I have spent the last two months committing patches to the VM. While we
have added a ton of much needed functionality, the stability of the system
has been ignored. By chance, I looked at thread synchronization design
problems this week. Its very apparent that
Geir Magnusson Jr. wrote:
did we ever bottom out on what range of GCC we'll support?
I have a patch I want to commit that is known to not compile under 4.1.1...
Hmm no I don't remember such agreement. I think GCC is mostly backwards
compatible, and anything that compiles on 4.1.1 should
Egor Pasko wrote:
On the 0x216 day of Apache Harmony Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
did we ever bottom out on what range of GCC we'll support?
I have a patch I want to commit that is known to not compile under
4.1.1...
Hmm no I don't remember such agreement. I think GCC
in ubuntu already - 4.0.3) or 4.1.x
(which are used in FC5 - 4.1.0 and Gentoo - 4.1.1). There are no later
versions on gcc.gnu.org than 4.1.1.
I think 4.1.x is better because it is stricter than 4.0.x when compiling
C++ (see [1]).
[1] http://gcc.gnu.org/gcc-4.1/changes.html
Gregory Shimansky
Salikh Zakirov wrote:
Gregory Shimansky wrote:
I think you could use 4.1.0 in Fedora Core 5. Since patch level
shouldn't really affect the C++ compilation restrictions, the same patch
should break on 4.1.0 as well.
Gregory, I've looked at harmony-1635.patch you've uploaded to HARMONY-1635
for the
whole JVM for each of its components makes no sense.
Gregory Shimansky wrote:
On Wednesday 01 November 2006 19:48 Alexey Varlamov wrote:
Gregory,
I observed similar quirks with paths while intergrating kernel tests
into build. AFAIU the Grand Design is the following: there are
abstracted
.
Including jvmti.test target into build.xml in the same way as
smoke.test doesn't make me happy.
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
Why not use junit?
If you mean why not use junit to loop over tests, then it is not the
case. I've used junit to do
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Geir
I actually was serious. Probably you were confused, I didn't write
build test, I wrote build smoke.test. The first one works ok, the
second doesn't.
It happens because test (top-level test target) is handled in a
different way from
for
individual test categories so it would be possible to run them separately
from the general test target.
--
Gregory Shimansky, Intel Middleware Products Division
because of
some more maintenance works done to infrastructure, or should I just be
patient?
I tried on different machines from command line svn client, eclipse subclipse
and kdesvn with the same result.
--
Gregory Shimansky, Intel Middleware Products Division
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
I don't want to create a huge discussion out of it like most [testing]
discussions become. Just want to know your arguments to create one
more tests category.
Because the current frameworks are... wacky. I can't turn off smoke
tests
and doesn't want to be killed
by its System.exit call can use SecurityManager to make it throw
SecurityException. I am quite sure that's what a java applet will get if it
tries to use System.exit.
--
Gregory Shimansky, Intel Middleware Products Division
/lnx_ia32_gcc_debug/deploy/jre/bin/java
-Dvm.assert_dialog=0 -classpath
/home/gregory/work/Harmony/harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_debug/semis/vm/gc_gen/_smoke.tests/classes
StackTest
Funny how it works picking up seemingly a random subdirectory in
build/lnx_ia32_gcc_debug/semis.
--
Gregory
it works
and own this secret like someone who wrote smoke build script does./joke
--
Gregory Shimansky, Intel Middleware Products Division
investigated in HARMONY-1560. There is no
patch for it though.
--
Gregory Shimansky, Intel Middleware Products Division
it was deleted as spam because it was cross-posted to
gmane.comp.java.activemq.devel news group. So it was seen only in news
group on gmane.
Link to the top level message is here [1].
[1] http://article.gmane.org/gmane.comp.java.harmony.devel/17239
Gregory Shimansky wrote:
Hiram Chirino wrote:
Hey
setup or thread manager files have a problem. I am
not sure, but I'll try to figure out what's going wrong.
--
Gregory Shimansky, Intel Middleware Products Division
a patch in JIRA,
I'll help to test it myself.
--
Gregory Shimansky, Intel Middleware Products Division
timeout on ClassGenericsTest and ClassGenericsTest4
tests on some slower machines, so it looks like they do require
increased timeout. Now I agree completely with patch which Vera attached
in HARMONY-1966.
--
Gregory Shimansky, Intel Middleware Products Division
and didn't specify a project, it showed all
possible status conditions for all apache JIRAs in the choice menu. I
saw Patch Available there. Several projects use it. So I thought
you're going to enable this status state.
--
Gregory Shimansky, Intel Middleware Products Division
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
It is with almost as much joy as being able to report TLP that I
report that patch available now works.
First, all thanks to David Belvins. I had been able to set the
patch available field in the default
Gregory Shimansky wrote:
2) kernel
*** java.lang.ClasssGenericsTest and
*** java.lang.ClassGenericsTest4 fail because of timeout, so I increase
timeout in kernel.test.xml
These tests work for me on Windows. But on Linux these tests fail with lost of
different exceptions
On Friday 27 October 2006 02:29 Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Strange thing is that when I *do* select Harmony project and click a
link in the box to show the specific custom fields project,
I have no idea what that sentence means.
then Status
menu doesn't have
Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Hello Nataly
It looks like a workaround to me to run the tests for VM. To run other
user applications we need a general solution about what to do with non
standard libraries which Intel compiler links with.
On Gentoo if you install icc
Nataly Naumova wrote:
On 10/24/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
BTW to test how things work with Intel compiler I've installed it on
Gentoo
(version 9.1.042, it is marked as unstable, but the most recent
stable is
very old - 7.1.006... which version do you use?) and failed
this - this probably should be elsewhere
- */
-
-if(!p_TLS_vmthread-stack_addr) {
-init_stack_info();
-}
-
void* stack_addr = get_stack_addr();
size_t stack_size = get_stack_size();
size_t page_size = get_guard_page_size();
--
Gregory Shimansky, Intel Middleware
the libs.
Could it be that native code is simply linked to these libraries so
native awt code libraries just don't load if you don't have X libraries
in the system?
--
Gregory Shimansky, Intel Middleware Products Division
are hereafter
discharged.
- 0 -
Comments please?
geir
--
Gregory Shimansky, Intel Middleware Products Division
!
junit.framework.AssertionFailedError: An InterruptedException must be
thrown in test thread!
This test works ok for me, probably after HARMONY-1823 was applied. Are you
sure you run the latest sources?
--
Gregory Shimansky, Intel Middleware Products Division
Testsuite: java.lang.ClassGenericsTest
Tests run: 8, Failures: 0
get to work on the transition
activities, but until then, just give yourself a well-deserved pat on
the back.
Do the votes made on [EMAIL PROTECTED] count or is your summary sent to
[EMAIL PROTECTED] enough?
--
Gregory Shimansky, Intel Middleware Products Division
and linux...
--
Gregory Shimansky, Intel Middleware Products Division
if I missed something.
[1]
http://download.eclipse.org/eclipse/downloads/drops/R-3.2-200606291905/ecj.jar
--
Gregory Shimansky, Intel Middleware Products Division
creates Test1931_2$1LocalClass.class while ECJ creates
Test1931_2$1$LocalClass.class.
It might be not the cause of the bug in this case, but I wonder whether naming
of inner classes is specified somewhere. Shouldn't names be the same for all
compilers?
On 10/23/06, Gregory Shimansky [EMAIL
:${env.LD_LIBRARY_PATH} /--
+env key=LD_LIBRARY_PATH
value=${build.deploy.dir}/bin:${env.LD_LIBRARY_PATH} /
Could anybody commit this?
--
Gregory Shimansky, Intel Middleware Products Division
understand the same under lazy resolution but it would be
better if you explained a bit how it is going to work.
--
Gregory Shimansky, Intel Middleware Products Division
that finalizers
implementation is not the one to be blamed and the problem is reproducible on
pure user code applications, not to show that this problem is so rare no one
in right mind would ever write an application to encounter it :)
--
Gregory Shimansky, Intel Middleware Products Division
and x86_64 support
should yet be implemented where necessary.
Profiling support in JVMTI (which is implemented ATM) is platform independent
and should work ok on any platform where drlvm compiles.
--
Gregory Shimansky, Intel Middleware Products Division
1 - 100 of 258 matches
Mail list logo
