xmlvm-users

[xmlvm-users] .class -> CLR pipeline

[John <jo...@tr...>]

Hello,

I'm interested in using xmlvm so I can develop jvm and .net vm
versions of the same app with as much shared code as possible. I've
been trying to get a basic hello-world example working but always get
the error "Could not create OutputProcess for target 'EXE'."

A bit of poking around in the source seems to suggest that the EXE and
CLR pipelines have vanished - in particular
OutputProcessFactory.createOutputProcess doesn't recognise these
targets any more. Will these be restored any time soon? What's the
current status of the clr backend?

Assuming this is just a glitch, can anyone tell me how far along the
clr backend is? Looking through the jvm2clr directory things look a
little... sparse. I wouldn't mind helping out but right now I wouldn't
have a clue where to start.

Regards,

[xmlvm-users] Garbage collector + Objective C

[Panayotis K. <pan...@pa...>]

I have this question:

iPhone does not have GC, while Java is the only way to go.
Given that iPhone is a small device, with limited memory (and they  
have disabled GC for a good reason), how is memory managed with XMLVM?

Re: [xmlvm-users] Garbage collector + Objective C

[Wolfgang K. <wol...@xm...>]

We make use of  reference counting and the autorelease pool mechanism
offered by Cocoa. Since reference counting is not as powerful as a
full-fledged garbage collector there is a limitation with this approach:
Using reference counting does not clean up unreferenced circular data
structures, what a garbage collector of course would do. So you have to
be a little bit careful to avoid this - otherwise the cross compiled
application would have a memory leak.

-- Wolfgang


Panayotis Katsaloulis wrote:
> I have this question:
>
> iPhone does not have GC, while Java is the only way to go.
> Given that iPhone is a small device, with limited memory (and they  
> have disabled GC for a good reason), how is memory managed with XMLVM?
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>   

Re: [xmlvm-users] Garbage collector + Objective C

[Panayotis K. <pan...@pa...>]

On 10 Οκτ 2009, at 11:54 μ.μ., Wolfgang Korn wrote:

> We make use of  reference counting and the autorelease pool mechanism
> offered by Cocoa. Since reference counting is not as powerful as a
> full-fledged garbage collector there is a limitation with this  
> approach:
> Using reference counting does not clean up unreferenced circular data
> structures, what a garbage collector of course would do. So you have  
> to
> be a little bit careful to avoid this - otherwise the cross compiled
> application would have a memory leak.

I've seen here
http://www.cokeandcode.com/XMLVM-OpenGL-Support-Patch-Commited
which talks about annotations.

I looked at the source code and I saw this, in file  
XMLVMNoAutoReleasePool.java
@Retention(RetentionPolicy.CLASS)
so, is there any way to "optimize" GC with annotations?

And, one more thing, is there a way to force send an object to  
oblivion, e.g. when we have cycle dependencies like the one mentioned  
above (and I just want to free some memory) ?

Re: [xmlvm-users] Garbage collector + Objective C

[Wolfgang K. <wol...@xm...>]

We have the NoAutoReleasePool annotation which inhibits the creation of
an autorelease pool. We use that to prevent anonymous inner classes from
being released right after creation when a method returns. This problem
occurred for event handler which should clearly live longer than just
for the method where they were created. So this is not really an
optimization.

We also do not have something like an explicit release since there is
nothing like this in Java or the Android API. To avoid memory leaks due
to circular dependencies you have to first break the cycle by manually
by deleting on of the references forming the cycle so that it is no
longer cyclic. After that you can "forget" the reference to the cycle
and the objects will be cleaned up.

-- Wolfgang


Panayotis Katsaloulis wrote:
> On 10 Οκτ 2009, at 11:54 μ.μ., Wolfgang Korn wrote:
>
>   
>> We make use of  reference counting and the autorelease pool mechanism
>> offered by Cocoa. Since reference counting is not as powerful as a
>> full-fledged garbage collector there is a limitation with this  
>> approach:
>> Using reference counting does not clean up unreferenced circular data
>> structures, what a garbage collector of course would do. So you have  
>> to
>> be a little bit careful to avoid this - otherwise the cross compiled
>> application would have a memory leak.
>>     
>
> I've seen here
> http://www.cokeandcode.com/XMLVM-OpenGL-Support-Patch-Commited
> which talks about annotations.
>
> I looked at the source code and I saw this, in file  
> XMLVMNoAutoReleasePool.java
> @Retention(RetentionPolicy.CLASS)
> so, is there any way to "optimize" GC with annotations?
>
> And, one more thing, is there a way to force send an object to  
> oblivion, e.g. when we have cycle dependencies like the one mentioned  
> above (and I just want to free some memory) ?
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>   

[xmlvm-users] [xmlvml-users] Re: .class -> CLR pipeline

[John <jo...@tr...>]

Some slight progress - have managed to cobble together a new
ClrOutputProcess so that .net bytecode is being converted again.
Actually managed to get a "hello world" exe out of it, which was nice.

However a slightly more complicated test trips things up, as the
following jvm instructions don't get translated:
jvm:new
jvm:dup
jvm:astore

jvm:new is interesting as it seems that it's just the first of a
handful of instructions responsible for creating a new object. The clr
on the other hand appears to be one big newobj instruction, so I'm not
sure how to write a suitable transform to do that.

I'm also not sure what the clr equivilents of jvm:dup and jvm:astore are.

Also doesn't seem to cope with anything other than a single .class
file as input at the moment. Any hints on how to deal with these
problems appreciated.


On Sat, Oct 10, 2009 at 8:49 PM, John <jo...@tr...> wrote:
> Hello,
>
> I'm interested in using xmlvm so I can develop jvm and .net vm
> versions of the same app with as much shared code as possible. I've
> been trying to get a basic hello-world example working but always get
> the error "Could not create OutputProcess for target 'EXE'."
>
> A bit of poking around in the source seems to suggest that the EXE and
> CLR pipelines have vanished - in particular
> OutputProcessFactory.createOutputProcess doesn't recognise these
> targets any more. Will these be restored any time soon? What's the
> current status of the clr backend?
>
> Assuming this is just a glitch, can anyone tell me how far along the
> clr backend is? Looking through the jvm2clr directory things look a
> little... sparse. I wouldn't mind helping out but right now I wouldn't
> have a clue where to start.
>
> Regards,
>

Re: [xmlvm-users] [xmlvml-users] Re: .class -> CLR pipeline

[Sascha H. <sa...@xm...>]

Hi John,
when I refactored our XMLVM structure a while ago, the CLR backend was not
added. The reason for this was mainly because we never had usable support
for JVM to CLR translation. As far as I know, the only stylesheets we have
so far are jvm2clr.xsl and clr-api.xsl, which together have not even 150
lines in them. So instead of putting this incomplete and very unusable
components back in we decided to not add it for now.

Right now we are focusing on the Objective-C and JavaScript backends, as the
smartphone market is the most important one right now. So I don't expect us
(the core team) to work on this anytime soon. However, if you feel that you
can do good progress on this, we are looking forward to help you on your
way. We have put a lot of effort in the other direction (CLR to JVM), as
this is actually a bit more difficult, but that's another story. Some things
will be easier to map from JVM to CLR. E.g. all the add instructions like
iadd, fadd, dadd etc can be mapped to a single add instruction in the CLR
world.

Again, if you wish to proceed on this we would be happy about your
contribution and could also help you if you get stuck.

// Sascha

On Sun, Oct 11, 2009 at 1:02 AM, John <jo...@tr...> wrote:

> Some slight progress - have managed to cobble together a new
> ClrOutputProcess so that .net bytecode is being converted again.
> Actually managed to get a "hello world" exe out of it, which was nice.
>
> However a slightly more complicated test trips things up, as the
> following jvm instructions don't get translated:
> jvm:new
> jvm:dup
> jvm:astore
>
> jvm:new is interesting as it seems that it's just the first of a
> handful of instructions responsible for creating a new object. The clr
> on the other hand appears to be one big newobj instruction, so I'm not
> sure how to write a suitable transform to do that.
>
> I'm also not sure what the clr equivilents of jvm:dup and jvm:astore are.
>
> Also doesn't seem to cope with anything other than a single .class
> file as input at the moment. Any hints on how to deal with these
> problems appreciated.
>
>
> On Sat, Oct 10, 2009 at 8:49 PM, John <jo...@tr...> wrote:
> > Hello,
> >
> > I'm interested in using xmlvm so I can develop jvm and .net vm
> > versions of the same app with as much shared code as possible. I've
> > been trying to get a basic hello-world example working but always get
> > the error "Could not create OutputProcess for target 'EXE'."
> >
> > A bit of poking around in the source seems to suggest that the EXE and
> > CLR pipelines have vanished - in particular
> > OutputProcessFactory.createOutputProcess doesn't recognise these
> > targets any more. Will these be restored any time soon? What's the
> > current status of the clr backend?
> >
> > Assuming this is just a glitch, can anyone tell me how far along the
> > clr backend is? Looking through the jvm2clr directory things look a
> > little... sparse. I wouldn't mind helping out but right now I wouldn't
> > have a clue where to start.
> >
> > Regards,
> >
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>